Finally, after years of wanting to make something like this, I've just received the prototype boards of my own cart design.
I have no idea if it works or not, still waiting on some components to arrive, but it sure looks cool. Check it out:
http://mywebpages.comcast.net/memblers/nespics/IM001757.JPG
http://mywebpages.comcast.net/memblers/nespics/IM001758.JPG
http://mywebpages.comcast.net/memblers/nespics/IM001759.JPG
System specs:
Up to 1 megabyte of EPROM, or 512kB of FlashROM (32kB pages). 1 million erase cycles on Flash.
32kB of WRAM (8kB pages) optional
32kB of VRAM (8kB pages), 4kB of which is used for all 4 nametables
PIC microprocessor (can be 20Mhz or 40Mhz, any 40-pin one pretty much)
minimum of 64 bytes EEPROM for non-volative storage (100,000 cycles). Flash is of course another storage option.
32 readable and writable 8-bit registers (function of which is totally configurable in the PIC firmware). 10,000 firmware update cycles.
6 pin I/O port, 5+, GND, and 4 I/O lines.
extra features:
.047" board thickness, standard for NES
gold-plated connectors
What it doesn't do, is run copied games. I suppose it might, but with the forced 4-screen nametables, probably not. This cart is strictly for new designs.
I hope this thing works, I'll definitely let everyone know when I find out.
It appears you've chosen high-speed CMOS (74HC) rather than low-power Schottky (74LS) for your discrete logic parts.
How much will this cost when populated with chips?
And will it have a built-in flash programmer?
And what about nametable switching, such as for status bars? I seem to remember some limitations of the four-screen layout for presenting a stable status bar without a scanline IRQ.
Will Nintendulator and FCE Ultra be patched to play programs designed for this cart, or would emulation of the PIC eat up too much CPU time?
Will it require cutting lockout chip pin 4?
Yeah, I'm gonna try 74HC parts first. It has pretty much every advantage that I know of over 74LS (especially availability). But I'm using sockets for every IC on the prototypes, I can experiment with other chips easily.
The chips and related components alone might cost maybe $20, more or less, bought in small quantity. And that's using one of the cheaper PICs, could be another $5-$7 for a high-end one. Then there's the board price, assembly (doing it myself), probably some other stuff I'm forgetting. The price can be cheaper if I could make a whole fuckton of them, but with my budget it seems I have little choice but to plan on starting with a small quantity and see how that goes. Not sure about the final price though, first things first, gotta make sure it works as planned.
It should be able to program a Flash ROM. A 29F040 chip is able to program itself, using standard bus read/write operations. It sounds real easy in the datasheet. So I'm counting on having the NES run it's code in RAM while it erases/writes the flash. Theoretically, one could use a ZIF socket to hot-swap the chip to program a whole one. I'm not sure about that though.
The Flash chip uses 64kB sectors, so I'd have my little operating system sitting in one sector (and that one would be write-protected, so nothing dumb could ever happen to it by accident). That would leave 448kB free for general use, 7 individual sectors.
I hope the 4-screen nametables won't be a problem, I'd like to hear more about that from anyone who has much experience with this stuff.
In the design there's a scanline counter, and CPU cycle counter. They will both be able to generate IRQs.
As for the emulator support, I guess that's up to emu authors if they want to deal with the PIC. For some of the basic functions they could probably simulate it, but there's nothing to stop any developer from putting their own routines inside the PIC or even enabling code protection so the PIC can't be dumped (evil, heheh).
It's a pretty decent little chip, every instruction (except branches, etc.) uses the equivalent of 4 6502 cycles. Considering it runs at 20mhz (or 40mhz on the high-end models), that's quite a bit of processing.
And the board has a place for a lockout chip (part # 6113) if you don't want to disable it (I'm not sure why anyone wouldn't want to, that's 4 less pins to worry about cleaning, heheh). Whether or not I can get a significant amount of those chips is unknown currently.
BTW, here's an extremely preliminary register list. Lots of changes/additions are planned, but feel free to check it out.
http://mywebpages.comcast.net/memblers/micromapper.txt
BTW, I forgot to mention how the cart receives data from a PC. My serial adapter will hook up to the I/O port on the cart for that. Or, it could use the controller port also (and just not be able to read controller data at the same time it communicates).
So the serial adapter is another thing that has to be figured into the cart's cost, for development purposes at least.
looks good
Yeah, this pcb, and the features seem to be very good. The scanline counter and the clock cycle counter are GREAT ideas.
Hmm... you know, if you absolutely NEEDED to bypass the 4-screen, wouldn't you be able to just tie some A lines together, like on other carts?
Also, a 1-screen mirroring controller (You know, one single nametable is used for all four ppu quadrants) would be nice, but it's not an absolute necessity.
Otherwise, it looks like this cart would be a VERY good... (ugh I can't think of a noun) It'd be good for new developments.
But this kinda has an issue, would emulator developers be willing to program this cart mapper into their emulators? This is the same problem I had when I was talking about the NES mouse. (didn't know if emulator authors would be willing to program support for it in their emulators) They probably would, your cart is more usable.
Edit: I need to scan posts more thoroughly for *links to documents that describe the registers*.
Drag wrote:
But this kinda has an issue, would emulator developers be willing to program this cart mapper into their emulators?
I am willing to do it, as soon as Memblers releases an official memory map.
Yeah, it should be possible to modify the cart somehow if 4 screens isn't suitable.
For the emulator support, the only registers I'm sure about are the bankswitching ones in that doc. All the other ones are still undetermined.
I received the components I was waiting for.
The cart is working nicely so far, everything is installed on it currently except the PIC. Looking good.
Woohoo, got the PIC running. Serial port works, and I managed to light up my on-board LED.
Now to test all the other I/O ports.
BTW, anyone have a preference on the type of Flash memory to use?
I can try AMD or Atmel style.
AMD is the one I mentioned with 8 64kB-sized sectors and >1,000,000 write cycles.
Atmel makes one that has 2048 256-byte-sized sectors, but does >10,000 write cycles and is a little more expensive.
I'm gonna go with AMD's chip, unless there's a strong preference for smaller sector sizes. 32kB sectors would've been nice, but that's just not available.
BTW, if you're not familiar with flash memory sectors (I'm not terribly familiar with it either), it seems to be like a sector on a disk drive, in that you can only erase and write whole sectors at a time, not just individual bytes. The write cycles, I believe is the amount of times you can erase/reprogram each individual sector.
Memblers wrote:
Yeah, I'm gonna try 74HC parts first. It has pretty much every advantage that I know of over 74LS (especially availability).
There's a difference between HC and HCT, which may affect compatibility with the TTL parts inside the NES. You might want to go with HCT eventually.
Quote:
I hope the 4-screen nametables won't be a problem, I'd like to hear more about that from anyone who has much experience with this stuff.
At least Gauntlet II uses a nasty hack to deal with a status bar in a 4-screen mirroring setup, namely doing a variable split-screen to skip over the scanlines of the second nametable that contain the status bar.
Quote:
As for the emulator support, I guess that's up to emu authors if they want to deal with the PIC. For some of the basic functions they could probably simulate it, but there's nothing to stop any developer from putting their own routines inside the PIC or even enabling code protection so the PIC can't be dumped (evil, heheh).
So if I wanted to do some testing on emulators, I'd have to build in compile-time options for a "common" mapper or your PIC based mapper, right? And dealing with a several-6502-cycle delay for mapper writes to take effect might be a pain as well, especially when trying to read data from several banks consecutively.
Quote:
And the board has a place for a lockout chip (part # 6113) if you don't want to disable it (I'm not sure why anyone wouldn't want to, that's 4 less pins to worry about cleaning, heheh).
Not every budding NES developer owns his NES console. Some use one bought by a parent and have no right to open the case. Some don't know how to cut out the middle of a flathead screwdriver to make it turn the proprietary screws that hold the NES case together.
Quote:
BTW, here's an extremely preliminary register list. Lots of changes/additions are planned, but feel free to check it out.
http://mywebpages.comcast.net/memblers/micromapper.txt
32 KB bankswitching? That'd kill all DMC usage in music engines unless you want to duplicate all waveforms in all PRG banks. I'd almost rather use UNROM style hardwiring, even if it would require a PCB redesign.
Is there another type of flash memory with sectors smaller than two PRG banks but with a decent number of erases per sector? (Single-level-cell memories have better life than multi-level-cell memories but are a bit more expensive for a given capacity.
Samsung's SLC page explains it in more detail.) If so, games could write to part of PRG flash to save a game state in the same way that FDS games and 8-bit home computer games wrote to the disk. Either that or make the EEPROM bigger than 64 bytes.
tepples wrote:
There's a difference between HC and HCT, which may affect compatibility with the TTL parts inside the NES. You might want to go with HCT eventually.
OK, I'll try them out next time I order some parts. HC seems to work fine, testing with a toploader (it's probably uses TTL parts, I dunno for sure).
Quote:
So if I wanted to do some testing on emulators, I'd have to build in compile-time options for a "common" mapper or your PIC based mapper, right? And dealing with a several-6502-cycle delay for mapper writes to take effect might be a pain as well, especially when trying to read data from several banks consecutively.
Well, other than for the debugging features, I wouldn't bother with emulators. Especially if you want to use any special features of the cart. Writing a game to support multiple mappers is cool, but sounds like it'd be kinda annoying when there's differences.
I've lost source codes to some of my older programs, and don't want to mess with changing others, etc., so one thing I plan on doing in my loader is automatically modify mapper writes. Won't be a problem.
Quote:
Not every budding NES developer owns his NES console. Some use one bought by a parent and have no right to open the case. Some don't know how to cut out the middle of a flathead screwdriver to make it turn the proprietary screws that hold the NES case together.
There are a lot of screws on an NES, but they're all standard, actually. On every front-loader I've seen, at least. But yeah, I can get all the needed lockout chips, even if I have to remove them from the carts in my own collection. I'd have to charge a bit extra for that, because desoldering equipment is probably gonna cost me. And getting chips for overseas regions.
It's a pretty necessary chip if you want to run it on any NES, but if you use a Famicom or a top-loader it's not needed.
Quote:
32 KB bankswitching? That'd kill all DMC usage in music engines unless you want to duplicate all waveforms in all PRG banks. I'd almost rather use UNROM style hardwiring, even if it would require a PCB redesign.
You can have a fixed 16kB bank at $C000, but the total ROM size would max out at 224kB (or 256kB w/o the BIOS). My loader will handle it.
Quote:
Is there another type of flash memory with sectors smaller than two PRG banks but with a decent number of erases per sector? (Single-level-cell memories have better life than multi-level-cell memories but are a bit more expensive for a given capacity.
Unfortunately, I think most of the good stuff is 3.3V and 1.6V. All I've got available to me currently is the 29Fxxx series.
Quote:
If so, games could write to part of PRG flash to save a game state in the same way that FDS games and 8-bit home computer games wrote to the disk. Either that or make the EEPROM bigger than 64 bytes.
You can do this with the current flash, might be cumbersome with 64kB pages, but it would work. The EEPROM is internal to the PIC, the high-end series has 256 bytes.
I've got a lot of ideas about things to do with it, one thing is that if the cart is hooked up to a PC anyways, you should be able to store and load files from there within your program. Like the Famicom disk system perhaps, but with gigabytes instead of kilobytes.
Status update.
Scanline counter works. Triggers about 3/4th of the way along (towards the right side) on my test program, this can be adjusted though.
CPU cycle counter works. It can be used simultaniously with the scanline IRQ too, works great.
Haven't had a chance to write my inital test code to my flash chip yet (have no device programmer). But I'm getting my code for it ready. I'll have at least 2 routines available for programs to use if desired, erase_sector and program_byte.
All the RAM works fine. My BIOS checks it at startup. Nametables work, they occupy the lowest 4kB of VRAM.
Gonna work on the USART next. See what kind of baud rate I can get with this thing.
Haven't written any code for the PC-side stuff, yet. Still learning (and re-learning) C so I can get started there. I might implement it into ucon64, but I haven't been able to get it to build. I seem to have bad luck with compilers.
Board will need to be redesigned to fix some mechanical problem, possibly one minor electrical one too.
Everything's going well, no problems at all so far.
Any new info? More pics at least
Yes, progress is being made. I just got my ROM burner a couple days ago, so I just began testing Flash on the cart. I've been able to get the NES to erase sectors and only program a few bytes so far, but it seems to be workable.
I'll post some pics soon.
Flash erasing and programming works fine now.
I'll need to make some changes to the board, so I need to do yet another prototype run after I do that..
I might be able to cut some costs by using surface-mount parts, it's something I'll have to pursue so I can use the better 18F PIC without raising the price for everyone. So the PRG-ROM should be PLCC-32 instead of DIP-32 in the final version. Hopefully it won't be much harder to build, I've never soldered surface-mount chips before.
I'm very excited about this cartridge. Please continue keeping us posted.
If anyone has any preference for the type of serial adapter I could use, let me know.
The previous way I had planned was having the adapter inside the cable hooked to the PC, it could plug into the cart, or the NES controller port (or various other 5-volt systems). This would also mean the connector could serve as an expansion port with 4 I/Os, 5V+, and GND.
Another way I'm thinking of doing it is just integrating the serial adapter onto the cart. It should be cheaper since I wouldn't have to make 2 boards. The PCB thickness requirements are different, so they can't go in the same run unfortunately.
So, I'm wondering if it matters either way to anyone. The external adapter is pretty nice to use with any cart, any system with a couple I/Os, etc. But if noone would end up using it much outside of Squeedo, it might be better off being integrated.
Another month passes. Sorry it's been so long, when I first started this project (nearly half a year ago already!) I really thought I'd be done by now, heheh.
But everything is progessing smoothly. My design has worked 100% as expected so far. If everything goes well, I should have a final (for real) prototype in my hands in early March. The next revision has some changes.
EPROM support is dropped, it'll use FlashROM pinout only.
On the software side, some good news if anyone is looking forward to doing some hacking with the PIC mapper. The design will be expanded to have 256 registers instead of 32. At $5x00-$5xFF.
On the hardware side:
MIDI-in option. Replaces RS232, so you can only use one or the other without a little soldering (or a switch maybe). The devcart version will be geared towards RS232 only.
The TTL-level expansion port is being dropped in favor of an RS232-level one. But VCC will still be provided on the port, in case anyone wants to power their own expansion circuit (and RS232 transceiver).
This is extremely exciting. Keep the updates coming, Memblers.
Oh, one other thing I forgot to mention. The LED will be gone in the next version.
Sucks to remove it, but without it the mapper will have a lot more registers.
I know you developed the Squeedo as a sort of super-MMC5-like cart and it is intended for future game development, but how easy is it to hack existing Famicom/NES games with common simple mappers, so that they can run on the Squeedo? If there was a tool that could auto-hack common games to run on the Squeedo, that would help sell lots of Squeedos, which means that more non-developers have Squeedo carts and therefore game developers can just release a ROM and people can run it on their Squeedo.
Guy wrote:
how easy is it to hack existing Famicom/NES games with common simple mappers, so that they can run on the Squeedo? If there was a tool that could auto-hack common games to run on the Squeedo, that would help sell lots of Squeedos
No, it would help Nintendo shut the project down for contributory copyright infringement. Look what happened to Bung when it sold GBC copier products. I'd suggest making two builds of a game: one designed to run in, say, UNROM and one designed to run in Squeedo.
There aren't many games that could run on Squeedo, even if they were hacked. The biggest thing is the nametable memory, Squeedo has extra VRAM where most games expect (and often require) there to be none. If you modify a ROM's header to enable "4-screen" mode and it looks screwed up when it runs in an emu, that's roughly how it might look on Squeedo (in the best case).
I'm sure it could sell more if it ran whatever game someone wanted it to. But if my design will be successful, I'd be a lot happier if it was successful as a completely original product.
So yeah, I am kinda going out on a limb here.
But anyways, it'll be able to run some existing ROMs as a matter of course. Most of the current homebrew games/demos aren't very picky about the type of cart it's on. I'll have some way to load them, because it'd be kinda dumb to require people to reassemble all the homebrew NROM programs to run them. UNROM and CNROM are some other types that might work. Still depends on the screen memory and scrolling though.
Memblers wrote:
There aren't many games that could run on Squeedo, even if they were hacked. The biggest thing is the nametable memory, Squeedo has extra VRAM where most games expect (and often require) there to be none. If you modify a ROM's header to enable "4-screen" mode and it looks screwed up when it runs in an emu, that's roughly how it might look on Squeedo (in the best case).
I'm sure it could sell more if it ran whatever game someone wanted it to. But if my design will be successful, I'd be a lot happier if it was successful as a completely original product.
So yeah, I am kinda going out on a limb here.
But anyways, it'll be able to run some existing ROMs as a matter of course. Most of the current homebrew games/demos aren't very picky about the type of cart it's on. I'll have some way to load them, because it'd be kinda dumb to require people to reassemble all the homebrew NROM programs to run them. UNROM and CNROM are some other types that might work. Still depends on the screen memory and scrolling though.
So NROM, UNROM, and CNROM? It lends your new hardware legitimacy as a real piece of NES hardware if it runs even a few official NES games. I know you probably hate being asked, but how much will a Squeedo cost and when are you going to start selling them?
I don't know what the final price will be for sure, but I feel it's pretty safe to say at this point no less than $75 and no more than $100. I'll try to ensure it's well worth it.. (or your money back! heheh
)
As for when I can start selling them, the only true answer is "as soon as possible". I've got to finish up my production version of the board, make sure it's totally bullet-proof (if not, rinse and repeat..), then the real production can begin. Maybe in a couple months, but that's very, very optimistic.
I received the prototypes of my new design this morning.
http://mywebpages.comcast.net/memblers/squeedo/pics/IM001919.JPG
As you can see, the board is black now, and much smaller.
Once I get it assembled and test it, I'll let everyone know how it went.
Cool ! You're really a master.
I just relised something :
If any simple multi-directionnal scooling code is designed to work with 4-screen mirroring, it would in theory work with both horizontal and vertical mirroring, and also on 1-screen mirroring. When you're drawing new data to the "same" mirrored name table, or if it's another one, it makes hardwarely no differences, exept some gliches that could appear. So a programm written for squeedo's 4-screen mirroring could also work on a standard cartidge.
Also, how do you want to use the PIC as a mapper ? I didn't got it wery well.
Yeah, if some care is taken it shouldn't be much trouble to write scrolling code that works with other cart's screen modes too.
About the PIC mapper, the NES can just write data to it (at $5x00-$5xFF), the command (what to do with the data) depends on the register location. Simple enough.
When the PIC wants to write to the NES, I've come up with an IRQ-based protocol where the NES will get interrupted and read twice from the PIC (once for data, again for 'command'). I'll have it all documented, and of course there will be routines that can do all this in the BIOS. The IRQ vector will probably point somewhere in RAM, for the best speed/flexibility (especially needed when using the sound synth, high IRQ overhead would be a problem there).
What you'll be able to do with the PIC, if desired, is write your own routines for each register (other than the default ones that do the basic controll stuff needed by the BIOS).
I'll try to supply some code templates and examples for the PIC program. I might supply full code or a listing of the NES BIOS also.
OK, it's been a while since I've posted any status update on this project.
Testing the 2nd revision PCB has taken longer than expected, due to a combination of manufacturing issues and a possible design flaw regarding the address-latch enable timing. The thing seems to work though, with some effort.
But there probably will be, unfortunately, yet another board revision needed.
The first version of the board works well, but it costs more to make. If there could be enough interest, I'm feeling inclined to do a small run for developers to use while further development continues. Then I would offer a trade-up for the next version once it could become available.
The software differences are only in the PIC (and simple, only a few I/O pins swapped). But with it being a smaller board run (maybe 25), and using more expensive parts on top of that, the price would be near the upper end of the price range I mentioned before ($100).
Production can begin within a matter of weeks. I've got my PCBs to use, I just need to acquire some parts and a couple more tools.
Here's how the boards look:
http://mywebpages.comcast.net/memblers/squeedo/pics/rev1.jpg
Serial/MIDI adapters (pic is kinda blurry):
http://mywebpages.comcast.net/memblers/squeedo/pics/adapters.jpg
And the next revision still needs more investigation, but it will be available also. It's basically the same.
http://mywebpages.comcast.net/memblers/squeedo/pics/rev2b-front.jpg
http://mywebpages.comcast.net/memblers/squeedo/pics/rev2b-back.jpg
The Squeedo rev2 board may be used in a future version of MIDINES.
http://www.wayfar.net/
I printed a test label to see how my print quality would look:
http://mywebpages.comcast.net/memblers/squeedo/pics/testlabel.jpg
http://mywebpages.comcast.net/memblers/squeedo/pics/testlabel-angle.jpg
Seems to be ok.
I'm going to be releasing an NES multicart to raise funds for building these Squeedo carts. It has Munchie Attack, Hot Seat Harry, and Solar Wars. It's sold out before I've even built the things. I want to make more game carts sometime later, so if I do that I can pay someone royalties if they want their game to be on a cart. There's no concrete plans beyond the first multicart in the series for now though.
Hey, sorry everything has taken so long, if anyone is still following this project, heheh. Latest development is a possible last-minute enhancement to the coprocessor specs.
One nice thing with Microchip's PICs is how they make newer chips that are still pin-compatible. With all the time this project has taken, I might as well do a 3rd upgrade, to the newer 18F4525 which is shipping in July. It's much the same as the previous 18F452, but it has more memory. Especially RAM.
http://microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1335&dDocName=en010298
compared to the older one:
http://microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1335&dDocName=en010296
Heheh, compare that to the first one I thought I would use.
http://microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1335&dDocName=en010233
Memblers wrote:
Hey, sorry everything has taken so long, if anyone is still following this project, heheh. Latest development is a possible last-minute enhancement to the coprocessor specs.
One nice thing with Microchip's PICs is how they make newer chips that are still pin-compatible. With all the time this project has taken, I might as well do a 3rd upgrade, to the newer 18F4525 which is shipping in July. It's much the same as the previous 18F452, but it has more memory. Especially RAM.
http://microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1335&dDocName=en010298compared to the older one:
http://microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1335&dDocName=en010296Heheh, compare that to the first one I thought I would use.
http://microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1335&dDocName=en010233
With all of that ROM space on the PIC, are you storing the firmware in the pic or in a separate ROM?
Jagasian wrote:
With all of that ROM space on the PIC, are you storing the firmware in the pic or in a separate ROM?
The PIC side of the firmware is in it's internal flash, starting at the lowest code addresses, since that suits it best. PICs architecture doesn't allow running code directly from RAM or external memory. But it can reprogram itself, and all that.
The NES side of the firmware still has to use the last 64kB sector in the main flash memory.
OK, time for another update about what's going on.
The PIC dev hardware I ended up needing to program the new chips is taking quite a while to get here. On the slow boat from Thailand I guess, heh. As soon as it gets here and I evaluate the new chip, I'll be proceeding to order whichever type works best. It's an agonizing wait, heheh. Looks like the 18f452 recently became a 'mature product' too, perfect timing.
Thanks to Jagasian's suggestion, I ordered some samples of FRAM chips by Ramtron (and they were kindly supplied). I figured I try them out as a non-volatile replacement for the WRAM on Squeedo, and they work. So if there's some interest in developing with these, let me know.
From a software POV it's no replacement for NV-SRAM though, since all their 5V ones have limited durability. As it puts it in the datasheet, each column (of 4 consecutive bytes) can be accessed 30 times per second for 10 years in the 32kB version (~$11) or 3000 times per second for 10 years in the 8kB version (~$6). Optimizing the memory usage somehow could make it last longer though.
Saving to the main flash memory is always an option on Squeedo of course. But automatic saving of individual bytes is kinda nice too, so I thought I'd put that out there as an option. Might be good for some applications.
With FRAM, reads also cause wear, right? Not just writes, as is the case with flash RAM. If Ramtron made unlimited durability 5v FRAM, could you replace the flash RAM with it? How much would that increase costs? Unlimited durability FRAM instead of flash would be ideal for homebrewers that like to do frequent tests of code changes. Has Ramtron made any statements about their 5v line and possibly extending it with unlimited durability FRAMs?
Speaking of "mature", the Altera Cyclone EP1C3T100C8 is only $10 per chip. Put that in the Squeedo along with that new PIC, and you could have a cart that has better support for popular NES mappers, as well as a midi-cart, and a Color Dreams "SuperCartridge". Basically a little something for everybody. Casual gamers would buy for the common mapper support, audio-philes would buy for the midi support, and homebrewers would buy for the SuperCartridge features (the highend PIC). But that would require allot of work, so maybe do something like that for Squeedo II?
Jagasian wrote:
With FRAM, reads also cause wear, right? Not just writes, as is the case with flash RAM. If Ramtron made unlimited durability 5v FRAM, could you replace the flash RAM with it? How much would that increase costs?
I haven't directly compared SRAM and Flash pinouts actually, but if they're the same then it would work. (they do use the same signals). Judging purely from the costs of the FRAMs that are available, I'm guessing a large 512kB one would be really expensive. Like well over $100, heh. So I'm guessing they won't be made that large until they can do it cheaply enough, which probably also means no 5V since I'm guessing there's not as much of a market for them compared to lower voltages.
And yeah, reading the chip does wear it down. It'd be awesome if they could make some unlimited durability 5V ones (and hopefully not much more expensive, heh).
Quote:
But that would require allot of work, so maybe do something like that for Squeedo II?
Yeah, actually I obtained an Altera JTAG cable but sadly I don't have anything to hook it up to yet, heh. I really do want to try a project with some programmable logic sometime, for sure. I've got a few crazy ideas.
I also thought about maybe trying out a SD card interface for Squeedo (using the expansion port). Maybe not immediately, but I think it's possible hardware-wise if it was desirable enough.
Alright, time for another monthly progress update.
I had to stuggle with some dumb bugs in the communications code, but that mostly works now. I'm running it at 115.2kbaud.
I took the Squeedo prototype permanantly off life-support (not using the EPROM emulator anymore, basically). And it's functioning really well. I implemented NSF flashing today, it already works fine with any non-bankswitched NSFs. Downloading a 24kB NSF takes around 6 seconds.
Next step is to do program loading properly. Once I no longer have to swap the chip out to reprogram the main BIOS code, I think it'll be safe to say it's basic functionality is complete.
Nice. Going to be intresting to see what kind of cool things you can do with the Squeedo. Any idea for when you can start to sell them?
Post some new PCB pics and some pics of it running code on a real NES.
Take it off!!
(woops, wrong forum)
Alright. There's not a whole lot to look at graphics-wise, but here's what I've got now.
Here's the cart running in a (partially disassembled) toploader. The pic came out really dark though, and is now pretty screwed up from me brightening it.
The LED is a big orange one. I'll likely be using a smaller crystal than the one on that cart (doesn't fit in a case too well).
Here's how it looks on the PC side right now, while selecting bank 2 and uploading/playing the Metal Gear NSF (no NSF info display yet though, it'll be easy enough to add).
NES display (just a partial mirror of what's on the terminal for now)
http://mywebpages.comcast.net/memblers/squeedo/pics/v01menu.jpg
The goal also is to be able to load an NES program just by running a command on PC and cycling the NES's power. That should make development pretty easy.
It'll autodetect the file you give it from several formats:
NSF
iNES
raw program (first 2 bytes are the load address), can load to RAM also.
squeedo format (TBD, but will contain extra stuff like the program title and PIC code/data)
Here's an up-close view of the rev2 PCBs with yellow soldermask, only being used for
http://www.wayfar.net/'s Midines 1.1 for now.
http://mywebpages.comcast.net/memblers/squeedo/pics/yellow.jpg
Not sure when I'll start selling it, but it'll be as soon as I'm satisfied with the stability of the loading code. Not long now.
Hey Memblers, if it's not too much trouble (and provided you don't mind doing it), could you maybe list what all the different chips are on that board? It'd give me some different things to learn (what they are, what they do etc.) while waiting on my book to get here... plus it would kill some time before classes start on the 22nd.
Of course, if it's too much trouble, don't bother
What is the difference between the rev2 and the larger Squeedo again? Will one have a superset of features of the other?
How much more difficult would it be for you to add a NES-side browser, so that you could run a PC-side server program that serves files from a specified directory on the PC to the NES-side browser, which downloads them from the PC and then triggers a reset via software? The benefit would be that people could use a small mini-itx like headless PC that is setup to simply serve files to the NES. It is less of a developer friendly feature and more of a user friendly feature, as it lets you have unlimited storage space, yet the userinterface is done through the NES.
Roth wrote:
Hey Memblers, if it's not too much trouble (and provided you don't mind doing it), could you maybe list what all the different chips are on that board? It'd give me some different things to learn (what they are, what they do etc.) while waiting on my book to get here... plus it would kill some time before classes start on the 22nd.
Of course, if it's too much trouble, don't bother
Alright, that's cool. I might as well describe what they do too, since saying '7400' doesn't say much, heheh.
74HCT139 - dual 2-to-4 line decoder. Half of it is used to enable WRAM, the other half is used to enable mapper writes.
74HCT00 - quad NAND gate. It does 3 seperate things. One NAND gate is used to invert the PRG R/W signal (to give PRG /RD). Another NAND gate is used to enable the 74hct139, when PRG-ROM isn't being accessed and the 'Phi2' signal is high.
The other 2 NAND gates in this chip are used to force the CHR-RAM to a certain bank when the NES accesses nametable memory. At any other time it'll use whatever bank is selected by the PIC.
74HC374 - latches the NES's lower address bits during a mapper write, and holds it for the PIC. I had some trouble with it on the rev2 board, since I changed it's clocking method (still not fully tested on rev2).
74HC04 - inverter, only used on rev1 for the latch circuit.
AM29F040B - Flashrom for PRG.
62256 x 2 - SRAMs for WRAM and CHR.
And of course, the PIC18F4525 microcontroller. It can work with cheaper PICs too, but I went for one with the best capability (alot easier to code for too, compared to the 16F family).
Jagasian wrote:
What is the difference between the rev2 and the larger Squeedo again? Will one have a superset of features of the other?
The rev2 switched around some of the I/Os on the PIC and has the RS232 transceiver on-board. There's also the MIDI receiver, but it can't be selected at the same time as the RS232. The latch was supposed to be able to get the lowest 8 address bits, but initially it seems to not be clocking properly. So if the latch doesn't work, rev1 software would take some minor code changes to run on rev2. Unless I do a 3rd version of the rev2 layout, which I'd rather not just yet, heheh.
Quote:
How much more difficult would it be for you to add a NES-side browser, so that you could run a PC-side server program that serves files from a specified directory on the PC to the NES-side browser, which downloads them from the PC and then triggers a reset via software? The benefit would be that people could use a small mini-itx like headless PC that is setup to simply serve files to the NES. It is less of a developer friendly feature and more of a user friendly feature, as it lets you have unlimited storage space, yet the userinterface is done through the NES.
That's something I want to do also, but probably not initially. I thought I would try to work this kind of function into a program like ucon64, so the NES can just use the PC hardrive like it's own disk system. When it happens, it'll be handled by the Squeedo BIOS. So any program besides the menu should also be able to load/save it's own files.
What are you using to program the 18F4525?
I'm looking for a low cost PIC programmer (or DIY) to program the 18F series. I'd like to be able to program the 18F2525 and 18F4525.
Recommendations?
Thanks
drk421 wrote:
What are you using to program the 18F4525?
One of these ICD2 clones (the red pcb one).
http://search.ebay.com/ICD2
If you search for "ICD2 clone schematics" you can find the info to build a similar one, but it does require a PIC on the programmer itself.
I tried the low-cost route (JDM programmer and Willem), problem is that the free software for those don't support the newer PICs. I guess they might in the future, I dunno though. With an ICD2, you can program any chip that's supported by MPLAB.
But if you only need one chip to work with, it could be cheapest to find someone to put a bootloader on one for you. That's how I got started before buying a real programmer.
Yep, that's the one. If you buy from that seller tho, expect it to take a while to arrive.
You know, I just realized that the Squeedo cart uses RS232 for connecting to a PC. This has one huge benefit over using a parallel port instead: there are USB to RS232 adapters. Of course it might require some additional software on the PC side of things, but at least that makes it more future-friendly. Computers are starting to lack RS232 and parallel ports, and Macs surely do not have them. USB, however, should be a common feature on computers for a long time.
Memblers, just curious how many layers your PCB's are? Looking at the photos and following traces from both sides, it seems like it must be more than 2. The routing doesn't look nearly as crowded as I expected.
All my boards so far are 2-layer. On Squeedo rev2 I put a lot of consideration into the chip placement. Route, move chips, find a better way, move chip(s), reroute, notice the board can be smaller, move chips, repeat.. heheh. It's a bit overkill, but I like it.
My UNROM cart has it's logic on the back of the board, I don't think I've taken any pics of that though. It's about the same size as a Nintendo NROM board, tiny.
I really wish Eagle's autorouter feature could allow you to have it auto place certain components as well. It'd make things a bit nicer, although I can only imagine how long it'd take on a large design.