Register To Post



 Bottom   Previous Topic   Next Topic

#1
SRAM cartridge?
Posted on: 2013/10/24 23:24
PVB Elite
Joined 2008/12/28
Slovenia
561 Posts
Highscore Top ScoreHighscore Top ScoreCoderContributorLong Time User (5 Years)Top10 Poster10+ Game RatingsApp CoderPVBCC 2010 EntryPVBCC 2013 Entry
I have had the basic idea for this for a long time but now that we are getting close(?) to having a mass-produced VB-PC cable, I have improved it and now it is much better than before.

Basically, the cartridge would be the same as a flash cartridge, but containing only SRAM memory. The advantage is that SRAM has (for all practical purposes) an unlimited lifetime, so the cartridge could be reprogrammed an infinite number of times without wearing out (and at a higher speed too?). The disadvantage would be having to change the battery periodically, but I think this is a small price to pay in exchange for those capabilities, and since this cartridge would be aimed at developers, it would be no problem simply to reprogram it again with a ROM image of the program in development if it loses data. Actually, it might not even have to be powered at all times, which brings me to my next point.

The big feature is that such a cartridge, if it exposed at least 2M of memory in the 0x06xxxxxx area, could be reprogrammed while being used in the Virtual Boy if there was a small loader program in the 0x07xxxxxx area that received the ROM image from a PC and wrote it to the 0x06xxxxxx area, then jumped to it. The ROM image would of course have to be compiled so it would use addresses in that area. While running, it could (perhaps by using an interrupt) call the loader to patch itself. Of course, the loader could also implement other features, for example dumping memory contents to the PC or taking screendumps (by dumping the frame buffers being displayed).

If the VB allows writing to the 0x07xxxxxx area (which it probably does not given that this area is intended for ROM, but my knowledge regarding this is insufficient), the ROM images would not have to be customized to use different addresses and they could use the 0x06xxxxxx area like commercial game cartridges for the 8K (or more) of SRAM intended for saving game data, but they would have to contain their own code to communicate with a PC and the cartridge would have to be programmable from a PC as well, otherwise you would run into a chicken and egg problem if you loaded a ROM image without any communication code. Or maybe the cartridge could contain code at 0x07FFFFF0 to jump to a loader at the end of the 0x06xxxxxx area, receive a ROM image from a PC and write it starting at 0x07000000 and ending before 0x07FFFFF0, jump to it, and still expose functions in the 0x06xxxxxx area for the program to access. The possibilities are limitless (well, at least theoretically).

So, VB hardware gurus, is this at least slightly possible to implement?
Top

#2
Re: SRAM cartridge?
Posted on: 2013/10/25 3:05
PVB Elite
Joined 2003/7/26
USA
1181 Posts
PVBCC EntryCoderContributorSpecial AchievementTop10 PosterHOTY09 EntryLong Time User (11 Years) App Coder20+ Game RatingsPVBCC 2013 Entry
While I have no direct experience, I believe DogP has written to flashROMs located at 0x07xxxxxx while the cart was in a VB. I believe the "write enable" line used for the expansion area (0x04xxxxxx) is also active during writes to the ROM area.

When I was pondering the problem of an SRAM cart, here is what I came up with:
1) The SRAM would be mapped to ROM space, as usual.
2) A bootloader, stored in a small (mask/OTP/EP/EEP/flash)ROM, would also be mapped in the ROM area.
3) There would be no conflict, because the /CE lines of the two (sets of) chips would not be enabled at the same time.
4) Upon booting, the ROM's /CE would be connected to the VB.
5) After optionally loading a ROM over the link, the VB would jump to the reset vector (0xFFFF_FFF0).
6) Logic in the cart would detect this jump and simultaneously disconnect the ROM's /CE while connecting the SRAM's /CE.
7) When power is removed from the cart and reapplied, the /CE switching circuit would be reset, ensuring that the ROM will boot next time the system is started.

It could be done with discrete logic, but a more compact (and likely cheaper) method would use some kind of programmable logic chip. If I were familiar enough with these to decide on the best one(s) to use, I would have already designed the circuit for this. (I have a lot of 5V SRAM chips salvaged from the cache of old PC motherboards). I would gladly help do some research on this, though.
Top

#3
Re: SRAM cartridge?
Posted on: 2013/10/25 8:36
PVB Elite
Joined 2003/7/25
USA
1441 Posts
PVBCC 1stCoderContributor#2 PosterHOTY09 EntryLong Time User (11 Years) App CoderPVBCC 2010 EntryPVBCC 2013 Entry
I had also considered an SRAM cart in the past, but there were several things that kept me from pursuing it. One... large 5V SRAM isn't easy to come by, and isn't cheap (at least it wasn't when I last looked... IIRC I have a lot of 512KB chips somewhere). Also, you'd need to make sure it was the low power SRAM if you planned to have it store the data across power cycles (otherwise you'd drain the battery fairly quickly).

My opinion was that flash can do pretty much everything that SRAM can do, though maybe just a little bit slower to write (though if you're talking about using a VB<->PC cable as the programming cable... either one will be faster than the VB link port). I doubt any of us would ever hit the endurance cycles on one of the flash chips. You could put a bootloader in the upper half of a flash chip (and waste half the flash), or use a second flash chip. Two flash chips (like using a flash chip and SRAM) will make routing more tedious since you'll need to route a bunch of duplicate address and data lines to multiple chips, plus the chip selector decoder logic. And I certainly haven't looked hard, but I don't remember seeing x16 SRAM chips, so that's even more tedious routing to have 2x x8 SRAM chips, plus a bootloader flash chip, plus decoding logic.

And yeah, I don't think there's any reason to connect to the 0x06xxxxxx addresses (pin 5 is /WE, which works just fine for writing at 0x07xxxxxx).

Overall though, I think slapping an FPGA on a cart with some modern memory is the way to go. If I had time to finish projects, I'd just build a real cart like I prototyped up a few years back: http://www.planetvb.com/modules/newbb/viewtopic.php?topic_id=4060 . I'd love to have tons of extra RAM and an FPGA as a co-processor. Maybe I can pay off my house and stockpile a bunch of food so I can quit my job and finish these things. :-P

DogP
Top

#4
Re: SRAM cartridge?
Posted on: 2013/10/27 23:04
Nintendoid!
Joined 2006/11/16
121 Posts
Long Time User (7 Years)
Quote:
It could be done with discrete logic, but a more compact (and likely cheaper) method would use some kind of programmable logic chip.


Dude, a 4-bit register would suffice for this. Just

- configure it as a shift register,
- have asynchronous reset connected to the #RESET line,
- clock connected to #ROM_CE, and
- parallel load connected to #LWR.

Then either make the input A a static '1' or D0 or something. The output Q_A goes to the boot ROM.
You should then use a little logic gate to invert this enable signal for the SRAM chip: tie the SRAM CE to deasserted state when #RESET is asserted to protect SRAM from spurious writes during powerup.

Quote:

Overall though, I think slapping an FPGA on a cart with some modern memory is the way to go. If I had time to finish projects, I'd just build a real cart like I prototyped up a few years back


An FPGA would be an excellent expansion lol. However, I do think an FPGA/CPLD for this kind of project would be overkill :-|

cYa,

Tauwasser
Top

#5
Re: SRAM cartridge?
Posted on: 2013/10/28 5:35
PVB Elite
Joined 2003/7/26
USA
1181 Posts
PVBCC EntryCoderContributorSpecial AchievementTop10 PosterHOTY09 EntryLong Time User (11 Years) App Coder20+ Game RatingsPVBCC 2013 Entry
There is a lot of stuff in your post I don't get, Tauwasser.

Quote:

Tauwasser wrote:
Dude, a 4-bit register would suffice for this. Just


Do you have an actual part number for this? It sounds like you're talking about a quad D flip-flop.

Quote:
- configure it as a shift register,


What is this configurable part that isn't an FPGA/CPLD(/PAL/GAL)? Do you just mean strapping inputs to outputs in a chain? Why not just use a purpose-built, serial-in, parallel-out shift register?

Quote:
- have asynchronous reset connected to the #RESET line,
- clock connected to #ROM_CE, and
- parallel load connected to #LWR.


What does #LWR mean? I assume you mean the ROM/EXP write strobe, pin 5. What is the purpose of doing this?

Quote:
Then either make the input A a static '1' or D0 or something. The output Q_A goes to the boot ROM.


Where on the boot ROM does Q_A connect? #CE?

Quote:
You should then use a little logic gate to invert this enable signal for the SRAM chip: tie the SRAM CE to deasserted state when #RESET is asserted to protect SRAM from spurious writes during powerup.


This part I get, although the point of this whole excercise is to make a circuit that keeps the SRAM disabled until it's time to switch.

Now, let me see if I get how your proposed circuit would work:
1) Upon boot, the "register" would be reset, thus containing four '0' bits.
2) Output Q_A, being low, would enable the ROM (and disable the SRAM).
3) Every time the ROM chip-enable line is asserted, the contents of the register are shifted.
4) Since input "A" is tied high, ones would always be shifted into the register. (Unless it's tied to D0, then I'm not even sure how to determine what gets shifted in...)
5) After one read from the ROM, a '1' gets clocked in, switching from ROM to SRAM.
6) The VB appears to freeze as it starts executing the (still empty) SRAM.

I don't think you can fit a link port-based SRAM programming routine in one instruction...

I probably don't fully understand what your circuit does. It's pretty much moot, though since, IMO, switching between the ROM and the SRAM shouldn't be based on a pre-determined number of read cycles. For maximum versatility, it should be totally under the control of the software running on the VB. Hence my proposal for triggering it based on a read from the reset vector. Would you care to apply your 1337 logic haxx0ring skillz to that problem?

Quote:

Quote:

Overall though, I think slapping an FPGA on a cart with some modern memory is the way to go. If I had time to finish projects, I'd just build a real cart like I prototyped up a few years back


An FPGA would be an excellent expansion lol. However, I do think an FPGA/CPLD for this kind of project would be overkill :-|


I agree that an FPGA or other large programmable device would be overkill for the cart I described. I was thinking more along the lines of a PAL/GAL like the (once ubiquitous) PALCE16V8 (or whatever similar device can still be found/programmed in sufficient quantity).
Top

#6
Re: SRAM cartridge?
Posted on: 2013/10/28 14:21
Nintendoid!
Joined 2006/11/16
121 Posts
Long Time User (7 Years)
Quote:

RunnerPack wrote:
Quote:

Tauwasser wrote:
Dude, a 4-bit register would suffice for this.


Do you have an actual part number for this? It sounds like you're talking about a quad D flip-flop.


I am talking about a quad DFF, specifially one with clock and write enable. Four bit counters have this option and are cheap.

I picked up the line "in shift register configuration" somewhere and it stuck. Yes, it means connecting the outputs to the next input. However, I did not explain in too much detail what I actually meant, my bad.

The purpose of not using a dedicated part is to be able to adjust the bus access cycle delay.

So you can either have byte and half-word access to only half-word access, or only word-access to our register.

Quote:

RunnerPack wrote:
What does #LWR mean? I assume you mean the ROM/EXP write strobe, pin 5. What is the purpose of doing this?


It's the write strobe for the least-significant 8 bits on the data bus. The meaning is the same as for the WRAM chips. You could also use #UWR if you so wished (only half-word/word access then). Look at this Wiki page where I updated the signal names and corrected the pinout.

It's /WE0 and /WE1 respectively. I doubt the table is correct, because the write strobes don't really depend on memory ranges but on bus configuration and width of write/read access. Which is why I stick to #LWR and #UWR.

Quote:

RunnerPack wrote:
Where on the boot ROM does Q_A connect? #CE?


Yes. And with some logic in-between to accommodate safe power-up the other output will go to SRAM.

Quote:

RunnerPack wrote:
IMO, switching between the ROM and the SRAM shouldn't be based on a pre-determined number of read cycles. For maximum versatility, it should be totally under the control of the software running on the VB.


It is totally under control of the software. You write to anywhere in the ROM region, either byte-wide or half-word-wide (so we have one bus access cycle). Then you jump to the reset vector of whatever you just wrote into SRAM.

You will have to bridge the delay
- from writing to our register,
- reading the JMP instruction -- one bus accesses in instruction format I,
- executing the JMP instruction

Instruction cache will have to be off for that, but I image it will have to be off either way or you risk data from your bootstrap being used in place of program instructions?

An ugly eagle drawing will suffice:

Open in new window


(This is the first time I used Eagle - and I hope it's the last time...)

Gating logic could be for instance 74LVC1G57 + Transistor + Pullup Resistor. Take 74HC161 for the 4-bit synchronous counter with asynchronous clear and we're looking at part costs of about 1.50 USD with no special programming equipment and no concern for high-voltages needed for PALs/GALs that would kill our other parts.

cYa,

Tauwasser

Attach file:



png  VUE_SRAM_Cart_Register.png (9.55 KB)
399_526e64ab86e00.png 1034X742 px
Edited by Tauwasser on 2013/10/28 14:33
Top

#7
Re: SRAM cartridge?
Posted on: 2013/10/28 14:26
Nintendoid!
Joined 2006/11/16
121 Posts
Long Time User (7 Years)
Quote:

RunnerPack wrote:
Would you care to apply your 1337 logic haxx0ring skillz to that problem?


Don't patronize me.

cYa,

Tauwasser
Top

#8
Re: SRAM cartridge?
Posted on: 2013/10/28 14:29
PVB Elite
Joined 2007/10/26
USA
603 Posts
ContributorTop10 PosterLong Time User (6 Years) Donator
Oki...non-hardware/software/barely a good player talking.

What would this be used for ? increasing the memory size/saving games...? just curious.

-Eric
Top

#9
Re: SRAM cartridge?
Posted on: 2013/10/28 19:49
PVB Elite
Joined 2003/7/26
USA
1181 Posts
PVBCC EntryCoderContributorSpecial AchievementTop10 PosterHOTY09 EntryLong Time User (11 Years) App Coder20+ Game RatingsPVBCC 2013 Entry
***Deleted by author***
Edited by RunnerPack on 2013/10/28 20:26
Top

#10
Re: SRAM cartridge?
Posted on: 2013/10/28 19:52
PVB Elite
Joined 2003/7/26
USA
1181 Posts
PVBCC EntryCoderContributorSpecial AchievementTop10 PosterHOTY09 EntryLong Time User (11 Years) App Coder20+ Game RatingsPVBCC 2013 Entry
Quote:

bigmak wrote:
What would this be used for ? increasing the memory size/saving games...? just curious.

-Eric


The proposed cartridge would allow developers to test code on hardware more quickly, since there would be no need to remove the cart from the VB to program, and the SRAM can be written to much faster than flash.

The downside for general gaming use is the need to battery-back the SRAM for it to retain its contents with the VB off (hence the use of flash in the flashboy).
Top

 Top   Previous Topic   Next Topic


Register To Post

You are not logged in.
Lost Password?
Register Resend Activation