It is currently Tue May 21, 2019 12:25 am

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 66 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
 Post subject:
PostPosted: Thu Apr 26, 2012 8:18 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 899
Quote:
Hey nocash... I can fill in the blank for some of these multi-tap games for number of players through your documentation.

Thanks! Most of the list is from wikipedia, http://en.wikipedia.org/wiki/SNES_Multitap (so I wouldn't call it "my" list).

Quote:
Lemmings 2 supports the super scope for shooting lemmings, but it does not appear to have software calibration.

Whew, one more rare scope-game. Hmmmm, calibration... it seems to randomly add/subtract different offsets each time when starting the game... ah, got it! Works like so: When the game starts, you need to aim the gun at the crosshair; that needs to be done quickly (within the first 1-2 seconds or so).
EDIT: With the black screen background & and thin crosshair, I am wondering if the calibration does actually work on real hardware - did anybody ever try that?

Quote:
Appearently NOCASH is down, just a notice

Nay, I am not down. And emubase.de... yes, it goes down once every some days... as far as I understood, that problem started after road rented a new server. So, he's still motivated running that site - I only hope he'll get around fixing that problems soon.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Apr 27, 2012 4:57 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 899
Btw. are there any good SNES schematics or service manuals anywhere?
The "best" SNES schematics seem to be these two:
http://neviksti.com/wiki/Schematics
http://www.caitsith2.com/snes/snes%20schematic.rar
the one one at neviksti seems to be sourced on an ultra-low-quality photo copy (so despite of the ultra-high scanning resolution, most of the text isn't legible).
the one at caitsith2 seems to be something rev-engineered by "electronix corp", but with some fundamental mistakes (like assigning an 18bit databus to the PPU for whatever reason).

Oh, aside from the scanning-quality problem... are there any schematics for the older SNES (with separate APU daughterboard), or for the later (cost-down) SNES version?


Top
 Profile  
 
 Post subject:
PostPosted: Sun May 13, 2012 1:17 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1470
nocash, I've expanded upon the missing information in the SPC7110 MCU (memory control unit).

It turns out our current emulation of it is incredibly flawed.

http://byuu.org/temp/spc7110-mcu.txt
I hope this will be helpful.

I'm all ears if you have speculation on the pathological handling of data ROM mirroring. And if anyone wants to send me Momtarou Dentetsu Happy or Super Power League 4 to borrow, I can confirm (or deny) the behavior on those cartridges as well.


Top
 Profile  
 
 Post subject:
PostPosted: Sun May 13, 2012 4:25 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 899
Great! Very nice to see the full memory map & details on bank switching, with used (and unused) bits! Thanks for uploading the txt file!

> $50:0000-ffff is the DCU (data compression unit) port.
That are was always bugging me. As far as I understand, the whole 64K are just a mirror of port 004800h? And there's no difference if one reads from port 004800h, from memory at 500000h, or 501234h?

> All SPC7110 cartridges contain 32kbit SRAM
64kbit! 8kbytes. (and when you double the size, guess it'd be 128kbit for the translation?)

> Data ROM size:
> When 0, bank &= 0 ( 8mbit data ROM.)
> When 1, bank &= 1 (16mbit data ROM.)
> When 2, bank &= 3 (32mbit data ROM.)
> When 3, bank &= 7 (64mbit data ROM.)
> Pathological mirroring behavior:
> If data ROM size = 0 and bank >= 4, reads return 0x00 always.
> If data ROM size = 1 and bank >= 4, reads return 0x00 always.
> If data ROM size = 2 and bank >= 4, reads return 0x00 always.
> If data ROM size = 3 and bank >= 4, reads return bank&3.
The 00h's are probably open-bus (from the Data ROM bus, not the SNES bus) (though FFh would be more common for open bus). Anyways, my guesses would be:
ROM size=0 --> two 8mbit ROMs (or open bus if 2nd ROM is missing)
ROM size=1 --> two 16mbit ROMs (or open bus if 2nd ROM is missing)
ROM size=2 --> two 32mbit ROMs (or open bus if 2nd ROM is missing)
ROM size=3 --> one 64mbit ROM
size=2..3 would be useful in case 64mbit ROMs haven't been available at time when making the chip. size 0..1 don't seem to be too useful.

> Mirroring of $00-3f:8000-ffff, $80-bf:8000-ffff
> Assume ROM offset $200000 is mapped to BANK0.
> Reading from $008000 would return ROM offset $208000
Okay, only upper 32K of the 64K banks... so no real LoROM support.
Quite possible that one of the VCC/GND pins (pin 80..86) allows to select LoROM mode.

> $4830: BANK0 (#$00 at power on)
> d7: SRAM enable (1 = enable; 0 = disable)
> d6-d3: always 0 when read
> d2-d0: bank select ... has no actual effect
> ... suggests to me that this register was meant to control a
> configuration where a cartridge contained *only* a data ROM,
> and no program ROM whatsoever. However, this behavior is not
> controllable by software, so it appears to be hard-coded to the
> boards themselves.
Would make sense. Might be another possible function for pin 80..86.

Ah, except, one thing: The SRAM enable bit in the same register! That might suggest that the other bits are SRAM related, too. A sram-size option could be useful, so they won't need different PCBs for each RAM size.
For example, on 32kbyte SRAMs, the second chip-enable (CE2, high=on) is replaced by A13. So, in theory, if you try to select a bigger size via 4830h, SRAM should be disabled in each second 8K-byte bank, like so:
00:6000-7FFF empty (A13 aka CE2 = low)
01:6000-7FFF RAM (A13 aka CE2 = high)
02:6000-7FFF empty (etc.)
03:6000-7FFF RAM
Maybe I am just dreaming there. I've fiddled with a SA-1 board last week, which lacked such feature; except for the solder pads (near the SA-1's battery) that can be used to manually re-wire CE2, VCC, and address lines for different SRAMs.


Top
 Profile  
 
 Post subject:
PostPosted: Mon May 14, 2012 12:24 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1470
Thanks. This chip definitely needs the most work of any remaining game coprocessors. It was basically emulated just enough to pass the self-test on first boot, with no effort ever extended to verify true hardware behavior. Not surprising, it's a bit of a bitch to run hardware tests on for your average person :P

I'm in a tough spot. I really need to work on the FEoEZ English translation, so I can't devote a lot of time to this, but at the same time, we really need the chip emulated right before we start hacking the game up. I despise hacks that wouldn't work on real hardware.

I suppose I'm going to have to at least do a cursory write+read over the entire register range to find more unmapped bits. The data port unit looks particularly screwy to me. It took me a long time to reduce that from the bit-blender that was the original Snes9X implementation.

Anyway, I'll post with any additional findings. But I can't promise a total RE effort at the moment.

> That are was always bugging me. As far as I understand, the whole 64K are just a mirror of port 004800h? And there's no difference if one reads from port 004800h, from memory at 500000h, or 501234h?

There does not appear to be any difference, no.
Indeed it seems like an absolute waste to me as well. If you need to stream from it, just use a fixed source address DMA.
I was careful to verify the range here, it definitely starts at 50:0000 and ends at 50:ffff.

Perhaps the SPC7110 designers were unaware of fixed transfer DMA (unlikely), or perhaps a fixed DMA from $4800 doesn't work in some instances (some kind of bus watching behavior? Also unlikely.) Hard to say.

> 64kbit! 8kbytes. (and when you double the size, guess it'd be 128kbit for the translation?)

Yes, sorry. Last second correction, I specified it as 8KB, but wanted consistency with ROMs in Mbit size. I've fixed the doc, thanks.

> The 00h's are probably open-bus (from the Data ROM bus, not the SNES bus)

That is quite possible. $50:xxxx return 0x00 as well. I'll have to log some SPC7110 DMA transfer addresses so that I can fake one and see what happens.

> Anyways, my guesses would be:

Appreciate your insight into speculation as well. You seem to have a better knack at this than me (judging by SFC Box and BS-X Satellaview work), so you're probably more right than me.

It's unfortunate though that we can't really know for sure unless we get another hardware guy to go at the pins.
But at least we can match the cart behavior.

> size 0..1 don't seem to be too useful.

I'm betting they are used in SPL4 (1MB Data ROM) and MDH (2MB Data ROM.)
$4834 as a whole really isn't useful at all. Just don't read out of bounds, and auto-mirror if you do (eg upper address lines not connected to the ROM chip.) No need for manual control of this.

> Quite possible that one of the VCC/GND pins (pin 80..86) allows to select LoROM mode.

Possible. They sure do allow for a lot of possibilities in a chip that isn't used much. But I guess they didn't know exactly how many games would use the chip when they designed it.

> Ah, except, one thing: The SRAM enable bit in the same register! That might suggest that the other bits are SRAM related, too. A sram-size option could be useful, so they won't need different PCBs for each RAM size.

I thought about that. To me it felt like the fact that 4830-4833 all had d0-d2 bits present that it was just an easier internal design to allow all four banks to be remappable. And yet something else is forcing the first bank to always be the program ROM. That you can overmap the program ROM onto the second bank leads further credence. There's probably an SPC7110 pin we can raise or lower that will turn the PROM off entirely, I am betting.

But either way, it could be SRAM related too. Again, all carts being 64kbit gives us no way to know for sure even with SNES code tests. I did try toggling between 00-07 here, and SRAM still mirrors its 64kbit across every bank exactly the same.

That $4830.d7 is SRAM chip enable (rather than just a write protect) was surprising. It will be annoying to have to leave that on in order to use the expanded 64kbit as scratch RAM. I like that it actually works, though. SuperFX and SA-1 RAM write protects always seem to give me trouble.


Top
 Profile  
 
 Post subject:
PostPosted: Mon May 14, 2012 7:15 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21389
Location: NE Indiana, USA (NTSC)
byuu wrote:
Perhaps the SPC7110 designers were unaware of fixed transfer DMA (unlikely)

Or it could be a design adapted from an architecture without fixed transfer DMA, or one where fixed transfer DMA is slower. Or perhaps it was just cheaper to decode that way.

Quote:
That $4830.d7 is SRAM chip enable (rather than just a write protect) was surprising. It will be annoying to have to leave that on in order to use the expanded 64kbit as scratch RAM.

Do Super NES games actually use cart SRAM as scratch RAM?


Top
 Profile  
 
 Post subject:
PostPosted: Mon May 14, 2012 10:31 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1470
I'm certain that some do, yes. SRAM isn't like Flash where you have to worry about write counts.


Top
 Profile  
 
 Post subject:
PostPosted: Mon May 14, 2012 10:59 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7711
Location: Chexbres, VD, Switzerland
The SNES is very different in this regard, as an extra 8kb of SRAM is negligible compared to the system's 128kb, so there is no reason to use it for anything other than saves.

It's not like the NES where adding 8kb of SRAM would multiply the amount of RAM by 5, and therefore it can be used for other purposes than saving games.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Mon May 14, 2012 12:45 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1470
It's specifically wise to do this for ROM hacks and translations, because otherwise you can never be 100% certain a game isn't going to try and use that same RAM you think is unused and overwrite at some key point much later in the game.

Even if you beat the entire game (with a logger to flag read from / written to RAM addresses), you may have missed some secret/bonus area or obscure event trigger.

And considering I want a full line of 16x16 VWF space, I don't want to try and reserve a huge block of 4KB+ of WRAM.

It would really be nice to know for sure how >8KB of SRAM works on these SPC7110 carts, but unfortunately no boards ever used more, so we kind of have to guess.


Top
 Profile  
 
 Post subject:
PostPosted: Mon May 14, 2012 8:32 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1470
Holy shit. Our entire SPC7110 emulation is substantially wrong in so many, many ways ... this is the most poorly emulated of coprocessor of all at this point, even beating out the terrible SA-1 knowledge.

http://byuu.org/temp/spc7110-mmio.txt
http://byuu.org/temp/spc7110-mcu.txt (updated slightly)

Where do I even begin ... well, notes are below.

nocash, if you'd like to work with me on reverse engineering this more (now, or sometime in the future), feel free to reach me on IRC or somewhere else, and I can run hardware tests that you request and see what happens.

Decompression Unit

$480b.d1 does not select between "0 = stream unmodified data ROM data; 1 = stream decompressed data ROM data." As far as I can tell, it has no effect. At least, not on my sample decompression.

$480b.d0, however ... wow. Complete mindfuck here. When this bit is set (eg $480b = #$01 or #$03), then $4807 has radical effects on the decompressed output.

I posted the tables of various values of $4807 in the mmio.txt file to show what effects it has on the sample decompressed output. I tried to replicate it under emulation through various means (add it to table address index, increment the data ROM read offset by $4807 instead of by 1, etc) to no avail. It ... almost looks like higher values 'compacts' the data more, but ... not quite. It's absolutely screwy. I could **really** use some help here. My worst fear is that this isn't a simple change in the decompression engine, and that there's a lot of additional functionality that we don't yet emulate. That algorithm was absolutely brutal even for neviksti to figure out.

I've also confirmed there's nothing special about $50:xxxx. It's a big literal mirror of $4800. Nothing more, nothing less.

The DCU status register ($480c) is substantially complex. I've been able to set and clear d0, d1, d2, d4 and d7 bits in it with various parameters. What's most wild is that it seems to start with d7 clear, then after a while d7 gets set forever, until you start a new DMA or read one byte MORE than you set for the compression length. Almost like it forces the chip to start decompressing again? And as we already knew, there's substantial waiting periods that increase more and more when you set a larger index into the decompressed data output (the chip has to decompress up to 64KB before it can start giving valid output.)

The data ROM read address is affected by $4834 (but not by $4830-4833.)

Data ROM read unit

First of all, the unlocking stuff is bullshit. It was a really awful guess to pass the SPC7110 first-boot self-test.
Basically, after power on, if you read from $4810 or $481a before writing to either $4813 or $4818, it returns 0x00.
All subsequent reads work as expected. Even without ever writing to any registers.
$4813/$4818 writes fill in the buffer, and reads from the buffer cause the SPC7110 to fetch the next byte then.

Much worse, however, is that absolutely nothing I try will allow me to read from $481a. The SPC7110 self-test does so, and ends up reading two different values from the port. I mimicked all SPC7110 register writes and reads just like my FEoEZ does, and all I ever get is 0x00.

Also, I really hate $4818.d5-d6, it feels like we are emulating two unique settings packed into one. And we still need to find out what happens if you force modes 3-255. Harder to do since I can't modify the data ROM, so we'll have to pick an arbitrary spot to start decoding against.

The data ROM read address is affected by $4834 (but not by $4830-4833.)

ALU

So there are very, very short delays before MUL/DIV results are valid. The delay length is constant (doesn't short-circuit for easier values, at least as far as my limited testing can tell.) I can't really get exact cycle counts because it completes too fast (1-2 instructions for MUL, 2-3 for DIV.) Reading early gives you pre-computed values. We *may* be able to reverse the algorithm this way, but ... fuck will that be annoying. It was hard enough for the SNES CPU.

d0 of $482f (ALU status register) returns 1 if the last operation was a multiply, and 0 if it was a division. Nifty.

At least our division by zero emulation was correct.

$482e resetting all the registers was complete nonsense. It does no such thing. The only thing that register is for is for setting the signed mul/div mode.

Side note: nocash, -0x80000000 / -1 = $4828[00 00 00 80; 00 00; 01 00] {482e=1}. Nothing unusual there.

MCU

Nothing more than I've already found here. Still can't get $4830.d0-2 to do anything useful.
I did verify that even with non-zero data read from $4800 and $4810, when you read from data ROM address 0x400000+ with $4834.d0-2 = #$00-#$02 (eg not #$03), it still always returns 0x00. Same for the empty bits in registers. There doesn't appear to be an exposed MDR for the SPC7110.

RTC

This thing has a whole ton of commands I don't yet support. But I see you've already realized that yourself. Curious how you verified exactly what type of RTC it was? Does it say it on the PCB or something? Some of the functionality of that chip will be nigh impossible to properly emulate ...

EDIT: okay, it's a separate chip entirely with a nice part marking, neat.
Can I ask where you got your data sheet from? The one I found is much less verbose.

I went ahead and emulated all of the chip functionality.
I do have some additional questions that I'm hoping you'll know (or the doc will say.)

1. you list WRAP for minute, hour, day, month, day of week. But if I set all of those bits to 1 (and clear them all on CE=low of course), it breaks the FEoEZ self-test sequence. Only doing it for minute alone works as expected.

2. might be easier to understand if you list the duty cycle as 1/128th a second to match the first rate setting's description as 1/64th. Easy enough to figure out.

3. say you set an hour IRQ, does the bit get set when the hour counter is incremented in R4-R5? Or does it do it an hour after IRQs are enabled? Or does it do it every hour after the cart was powered on, or possibly after CE is set to high?

4. will the IRQ still fire if the chip is in stop, hold or reset?

5. what is the difference between stop and hold?

6. is Epson completely silent about the test register? If it's not too screwy, maybe I'll have to stab at that one myself ...

7. are the RTC regs cached on CE=low, or are they real-time values? That you say you have to bail out when wrap is set suggests the former ... but that seems wasteful to have all that extra RAM.

8. how does wrapping of bad values work? Eg we can test if(++seconds >= 60) minute(); or if((seconds %= 60) == 0) minute(); You mention that time/date can be corrupted on changing AM/PM ... is that from the manual? Any details on how it can be corrupted?

9. there is $4840.d1 ... I wonder what that bit is used for. Boy I sure hope it's another RTC stop bit </sarcasm>

10. I don't think our $4842.d7 flag is good enough. It's locking up on rare occasion when I support an actual delay for clearing the flag. I will have to test that further.

Looks like the start date is limited to 1995-2014. Guess we better get the game translated before then, huh? :P

MMIO

In general, the CPU MDR doesn't fill in the empty bits of MMIO regs either. They're always zero no matter what.
But there are registers the SPC7110 doesn't respond to at all. Those return the CPU MDR.
And there's no other mirroring other than the repeat in banks $00-3f|80-bf. It's only in $4800-4842.

There's a slight persistence to the registers even across power cycles.
It's possible to fail out the self-boot test with rapid power cycles (obviously once you pass the test once it never runs again, until you wipe the SRAM.)


Top
 Profile  
 
 Post subject:
PostPosted: Tue May 15, 2012 1:52 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 899
RTC-4514 Appliction Manual, 21 pages,
http://download.inventronik.de/MiniFlex ... tc4513.pdf

The time isn't cached/latched during reading, hence the WRAP bit, which tells you that the time changed during reading.

Except, I think when setting HOLD, then the is latched, and can be read without wraps. After clearing HOLD it increments the second (if needed). The downside is that it can only "increment by 1" (ie. seconds may get lost if HOLD is set for longer time).

And STOP should just completely stop the time.

Hour IRQ should trigger each hour (when minutes=00).

> there is $4840.d1 ...
Huh. what is that? Is it write-able? Does the software use it... maybe as read/write direction flag? Or is it unused by existing code? Or maybe sth like 4bit/8bit data size selection, or serial transfer clock rate...?

----

Division:
> -0x80000000 / -1 = $4828[00 00 00 80; 00 00; 01 00]
Good to know. Not too unusual - but note that result "should" be +80000000h (not -80000000h), though that's, of course, impossible for signed 32bit range.

Glad to hear that "reset all maths registers to 00" stuff was bogus.

----

Your findings about decompression & data rom access look great!

Don't know if/how I could help there. At the moment I am trying to understand the VS Unisystem (NES-like arcade machine); my brain is currently filled with palettes, checksums, and mapper numbers - and trying to think about decompression just makes me dizzy.


Top
 Profile  
 
 Post subject:
PostPosted: Wed May 16, 2012 9:03 am 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 899
> On division by zero: quotient = 0, remainder = divisor (low 16-bits)
that should be "remainder = dividend (lower 16 bits)", right?
"divisor" would just mean zero (since it's division by zero).


Top
 Profile  
 
 Post subject:
PostPosted: Thu May 17, 2012 1:30 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1470
Well ... we're in trouble. More info on my board:
http://board.byuu.org/viewtopic.php?f=1 ... 0&start=15

But basically, $4807 is some kind of bit deinterleave pattern.
I can't even begin to imagine what the hell this could be useful for, since it basically ignores lots of the decompressed output data.

Code:
  unsigned stride = 2 * mode, blocksize = 0x20 * mode;
  for(unsigned dp = 0, sp = 0; sp < buffer.size() - blocksize;) {
    for(unsigned base = 0x00; base < 0x20; base += 0x10) {
      unsigned lp = sp + base;
      for(unsigned word = 0; word < 8; word++) {
        output[dp++] = buffer[lp + 0], output[dp++] = buffer[lp + 1];
        //this looks evil, but basically add 0x10 every time we cross a 16-byte boundary
        lp = lp + stride + 0x10 * ((lp + stride) / 16 - lp / 16);
      }
    }
    sp += blocksize;
  }


(It is possible this varies per decompression mode. I haven't gotten that far yet.)

But we have much bigger problems now. Apparently our decompression code is incomplete. It breaks down when you hit an edge case like tons of 0xFF values fed in a row. Kind of reminds me of the problem with the S-DD1 that Andreas Naive didn't emulate. The real SPC7110 seems to die and output a constant stream of the same value. Our emulation just keeps on spitting out noise.

I cannot emulate $4807 until we emulate register $4800 correctly, because my $4807 falls apart once you start reading past where the SPC7110 dies. And even better, that's a separate issue, because I was trying to deinterleave the data logged from hardware and failed. So the deinterleave goes inside of the decompression, it's not a post-processing effect. Hence, we can't figure it out until we get regular $4800 correct.

A DMA may fail (since you have to decode basically 0x400 bytes to get each subsequent byte of output), but my read a byte and send via USART is slow enough that the SPC7110 can keep up, even in the monstrous $4807=#$FF case.

I need help from someone who understands the SPC7110 decompression algorithm. There's no way I can fix this myself :(
I can supply all the hardware logged data anyone would like, however.

Also, $481a always reads out as 0x00. It does however increment the data ROM address as the current code describes. Still can't make $4808 return anything. RTC BCD is insane. Lots of issues with invalid data, but I should be able to RE that from the tables I dumped. 24H mode won't let you set AM/PM bit, 12M mode won't let you set D5 of Hour. RTC ready flag is set ~64 CPU clocks before it's ready. Read without ~4x NOP after and it fails. RTC has its own MDR. It goes crazy if you write to it or strobe CE while doing a 30ADJ and not waiting the 125uS. And the list goes on and on and on and on.

> that should be "remainder = dividend (lower 16 bits)", right?

Yes, sorry for the mistake.


Top
 Profile  
 
 Post subject:
PostPosted: Thu May 17, 2012 5:18 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 899
I really don't understand the decompression algorithm. You've seen my pseudo-code decompression functions, don't you? They are a bit tighter than the reverse-engineered code, eventuallly making easier to see what is going on, and to spot where overflows might occur.

Might be useful if you log min+max values for all variables; espcially on the "top" variable. Then decompress some valid data blocks. That should give you the valid min+max ones. Then decompress some stuff that isn't intended to be decompressed, and watch cases where it exceeds the min+max values.

Timing might be also a problem, at least when using DMAs which expects the decompressed bytes to be ready within 8 clks. But as far as I understood, you are already using non-DMA reads for that purpose? Does that make a visible difference? More distorted results with DMA, and less distorted without DMA?


Top
 Profile  
 
PostPosted: Fri May 18, 2012 7:24 am 
Offline

Joined: Thu Dec 29, 2011 5:41 pm
Posts: 172
can an Address Decoder 74LS139 be soldered in the same socket of a MAD1 chip and work fine? (save, etc?)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 66 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: calima and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group