Jump to content

Memblers

Member
  • Posts

    18
  • Joined

  • Last visited

  • Feedback

    0%

2 Followers

About Memblers

  • Birthday 02/18/1981

Personal Information

  • Location
    Indianapolis, Indiana

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Memblers's Achievements

Peasant

Peasant (1/20)

22

Reputation

1

Community Answers

  1. I have a prototype of Garage Cart, has sockets for EPROMs. It's what I used to test it. One of my favorite homebrew protos (I consider it one, at least) is The Incident. It was the first release to use GTROM, I had a small run of green (vs black for production) proto boards made that I hand-soldered, maybe 6 or 8 of them, before the big production run. I gave 2 of those to KHan. Later, when I got my CIB copy of the game, it's the normal release except using one of those green proto boards. So that was awesome.
  2. The chemical reaction happening inside the AA releases hydrogen gas. There is some material inside to absorbs it, but eventually there's too much gas, it gets vented out.. along with the other battery contents. Whatever reaction is in the CR2032 seems to be a lot milder. It only puts out a little current. You can touch an LED directly to a lithium coin-cell and it will light up. Do that with any other battery, if you don't add a resistor it becomes an SED (smoke emitting diode).
  3. They age over time, regardless of RAM contents. What affects the drain rate the most is the individual RAM chip, and seems that Nintendo must have been pretty strict about their suppliers, because NES cart saves seem to have great longevity. At my job I've repaired/refurbed quite a lot of lab equipment with CR2032s. They are pretty stable, even on a valuable cart I wouldn't worry about it. Out of.. 1000+? (stuff that had been in the field for 10-20 years, in a harsh environment).. I've seen only one that that leaked a little (no damage, just a little white stuff around the seam). And some battery controller chips do have a "freshness seal", that only starts using/draining the battery after you've powered on the device on for the first time. You won't see that in a game cart though.
  4. Genesis I/O is all digital, so the analog to digital conversion is happening inside the controller. There is some info and code examples here: http://gendev.spritesmind.net/forum/viewtopic.php?t=2733 https://www.sega-16.com/forum/showthread.php?30101-XE-1AP-Analogue-Controller-Cyber-Stick-CZ-8NJ2-XE-1AJ-Driver-(Source-JP-docs) Basically, it looks like you use the controller's output to make it start the ADC conversion, then read the port multiple times to get all the data.
  5. That would help. It totally depends on the design, it's also common for devices to have factory calibrations, serial numbers, decryption keys, a portion of the firmware, a lot of stuff stored in flash that isn't meant to be upgradable. It's also common, but not universal, for there to be a "bootloader" portion of memory that is untouched by firmware upgrades. 150 years from now, if somebody wants to restore a 2020 automobile, they might find themselves having to reflash 50 microcontrollers all throughout the system, assuming they still have the code/data to put on it. By that time NES systems and carts (at least the licensed ones) will still work, at the most one would only have to replace capacitors and clean the connectors.
  6. If you've heard of quantum tunneling effect, from quantum physics, that is what allows Flash and EPROM to be programmable, and the reason for the bit rot. A cell that stores a bit of memory is electrically not connected to anything. When programming, the electrons are more energized than usual, and they are more likely to teleport themselves through that solid barrier. A bunch of electrons get trapped in that cell. But we can't keep them there forever, because the way the world works is weird AF, those electrons don't exist at a particular point, but rather a probability cloud. It could be in the cell, it could be leaving the galaxy at light speed, it's just more likely to be nearby. But being anywhere outside that cell is enough for data to be lost, once enough electrons escape. So, that's why Flash and EPROM technology works. I expect there are going to be tons of embedded devices that won't work in the future, once the factory-programmed firmware is corrupted.
  7. Late to the party, but.. "hex" in the hex buffer just means there are 6 individual buffers in one chip. Like 74HC00 is called a "quad NAND", means there's 4 NAND gates in one chip. U3: 74LS139 - demultiplexer - takes small number of NES CPU address lines, and outputs individual enable signals for different chips. This is how the NES RAM, PPU registers, and cart area are mapped into CPU address space. Could also call it a binary decoder. Like a 3:8 decoder for example, as we know 3 bits can represent 8 values. The 3 bits are encoded in binary, and the 8 outputs pins are active one at a time for each value. U2: 74LS373 - PPU address latch. Allows the PPU chip package to have less pins. Without this, the PPU wouldn't fit in a DIP-40 package, it would have needed 7 more pins to support the same size memory. U7,U8: 74HC368 - inverting buffer / line driver. As a buffer, protects the NES CPU inputs from being directly connected to the outside world. U9: 74HCU04 - unbuffered inverter. I don't fully understand the physics behind this part. Seems to be usable as an amplifier. The six buffers in there are used individually for a lot of things, the NES audio goes through one, it makes an oscillator with the 4mhz crystal for the lockout chip, it inverts a PPU A13 for use as a nametable memory enable, the rest of them relate to the lockout chip clock and reset.
  8. I play NES pretty much exclusively on CRT. From what I understand, PAL artifacts are completely different from the NTSC ones. Patterns that are OK on NTSC might look bad on PAL, and vice-versa. It doesn't seem like any emulators that I use have a PAL filter. Looking on NESdev though, at the end of this thread somebody wrote a PAL filter for RetroArch. I have no idea how accurate it is, I have a PAL NES for testing but unfortunately I haven't yet found a TV that will work with it. https://forums.nesdev.com/viewtopic.php?f=3&t=12788
  9. It looks like the Power Pad outputs to the same pins as the Zapper, so it would be easy to make a "dumb" Y-adapter that combines controller+power pad. The Power Pad could connect to J2 on my drawing for Pad+controller. With some changes it would be possible to combine signals from two Power Pads. Like combining the controllers, the game wouldn't be able to distinguish the two and you could press a button on either one of them. Is that useful? I could add that feature pretty much for free since that 74HC08 has AND gates left over. And yeah, the IC in the NES controller is the standard CD4021 which is easy to buy. 74HC165 I used isn't pin-compatible but it does the same thing (looks like I'm going to change to 74LV165 though, since it has schmitt-trigger inputs and that will help with button de-bouncing). So I figure what I'll do to keep it solder-free, is if we need some alternate configs maybe I'll put DIP switches on there to select them. And then use screw terminal blocks for the wire inputs.
  10. I was going to build an NES arcade controller several years ago, but had not gotten around to doing it. I have a drawing of the circuit (attached) but I have not done the board layout. This has 10 wire inputs for the microswitches, 8 NES buttons + 2 grounds. Every button needs a signal wire + ground, and you would daisy-chain the grounds together when assembling the control panel. This design optionally can use two NES controller sockets (J2, J4 in the drawing). One connector is for a light gun, and the other a normal NES controller. The pins are all combined at the output to NES (J3), so you can use them all at the same time. There is an AND gate that combines the shift register outputs from 2 controllers, and the Zapper simply uses different pins, as usual. There is a select jumper on that board that would let it ignore the arcade button inputs, instead of a Zapper it can also combine 2 normal NES controllers. A real trackball interface (not PS/2 or USB thing) needs a quadrature decoder. I haven't built one yet, it doesn't look hard but I'd say it's non-trivial at least. AFAIK there isn't an off-the-shelf chip you can readily buy for that, so it probably will need to be made from a bunch of discrete parts, programmable logic, or a microcontroller. Not anything expensive, just takes some design time. Should I finish this board? It could do more than 8 inputs, just need to add more shift registers and input wires into the design.
  11. Yeah there was something Beau said on the tools/assemblers episode, I don't actually remember what exactly. Not anything important, just something I got an unintended laugh out of while I was at work (wearing headphones). I've given NESASM a lot of crap over the years, by way of directing people away from it, but it actually is a good assembler if you're OK with requiring the specific indentation and bank size. And it's really weird that I've been doing NES stuff for so long that I'm kinda nostalgic about it, haha. The source code to Mouser + NESASM was my version of Nerdy Nights, back when I was like 15-16.
  12. From what I understand, there wasn't an official development software or hardware, licensed developers were only given some docs in Japanese. Based on what people from Beam Software and Software Creations have said. The only assembler that I've ever heard named as being used for NES stuff, was one called 2500AD. And that's only because some "Hong Kong Originals" like Pocahontas, Boogerman, were known to be programmed with it. If you want to see something crazy, look at Color Dreams' source code that has been released. Very little of it is assembly, the games itself are mostly some kind of custom-made scripting language. Some games actually have some of their source code in the ROM, which can be seen on The Cutting Room Floor website http://tcrf.net/ but it's usually just tiny snippets. One that has a substantial bit of source was actually one of Nintendo's service center test carts (used to be distributed as "cart.nes"). My own history of NES assemblers was starting with MagicKit/NESASM, which was brand new and had awful bugs at that time, so I switched to DASM, which didn't have .incbin at the time, then to X816 because I liked the unnamed/anonymous label support, and eventually moved to CA65 once I saw that it basically has any feature one could want. I grew into using more of its features over time. Now I'm even using the C compiler quite a bit, it's fairly easy to mix with assembly. I also use ASM6 for smaller projects. It's just simple and straight-forward. It also allows unnamed labels. The NESASM3 limitation usually referred to is the 8kB banking requirement. It's based on MagicKit which is a TG16/PCE assembler, which is why there are 8kB banks and the unusual syntax for writing to zeropage (you have to always type "sta <label" instead of "sta label", because $00 and $0000 are different memory locations on a TG16). The 8kB banking, when the NES mappers are usually 16kB or 32kB, coupled with the bug (I consider it a bug) that NESASM doesn't have a warning or error when you cross a bank boundary, it just drops the data so that leads to more micromanagement (especially if you need to completely fill up the ROM without padding). NESASM also can't assemble relocatable code, which is a common thing to do, copy code into RAM and run it there. MagicKit/NESASM3 does have a good macro system though. edit: Despite what's been said about me on a certain podcast, lol, I've used the latest version of NESASM for a very long time. What sucks is that there are multiple branches NESASM, and none of them updated the documentation to say what was fixed or added. There is at least NESASM3, and Unofficial MagicKit by zzo38, the latter seems to have many new features, I didn't have much luck using them myself though.
  13. Did I tell you @SoleGoose that somebody has made 3D models for a VB extension cable? I could get one end of those 3D printed, and build some easy to use VB to NES adapters, assuming the creator of the model is OK with it. I still have a ton of NES controller cables.
  14. Castlevania is one of the first games I remember picking out at a store when I was a kid. Had to have been from the cover art, because I'd never heard of it. I couldn't have seen the back of the box either, because they were in a display case. That worked out well.
  15. It turns out that reading the palette just isn't reliable, it works on some PPUs and not others. There is a test program in this post here: http://forums.nesdev.com/viewtopic.php?p=99773#p99773 Like using the $2004 register, now it makes sense that no games ever did it that way. Except for Micro Machines ($2004 reading), and as a result it's screwed up on older Famicoms (and maybe some rare NESes with early chips, if that combo exists). I didn't know that either, before you asked.
×
×
  • Create New...