Offline

Great thanks, will try this soon!! Been wanting to put some new roms on there without having to dig out the old PC smile

Offline

Ah i missed that it only does a single rom sad Well, it seems like it would work for that at least, recognises my cart on Mac. Look forward to future versions, hope you do manage to make it handle multiple roms smile

Offline

oops double post

Last edited by Cementimental (Sep 23, 2016 10:23 am)

Offline
Naptown

https://github.com/Drenn1/ems-flasher

You can grab the menu.gb or menu.gbc rom from here, concatenate the roms you want onto it, then flash it onto the cart. The only drawback is you would have to do this every time you want to change out a game.

Last edited by urbster1 (Sep 23, 2016 2:24 pm)

Offline
urbster1 wrote:

https://github.com/Drenn1/ems-flasher

You can grab the menu.gb or menu.gbc rom from here, concatenate the roms you want onto it, then flash it onto the cart. The only drawback is you would have to do this every time you want to change out a game.

I've found the same project myself just today! I think there's no way out to reflashing all the bank everytime you change a game... or is there?
Does the official program allow you to change a single ROM in a bank with more ROMs? I ask because I never used it (I'm a Linux-only guy so before I wrote my program I always used ems-flasher)

Offline
Naptown

I've been using that for a while on Cygwin because I never got the stupid EMS drivers to work, so I can't tell you what the "official" software does, but it uses the menu designed by MottZilla. He explains a bit more about it in this thread: http://forums.nesdev.com/viewtopic.php?t=9456

The Drenn1 version of the ems-flasher does allow you to add/remove a single ROM in a bank, although I haven't peeked at the code so I couldn't tell you that it wasn't just automatically reflashing the entire bank.

Offline
urbster1 wrote:

The Drenn1 version of the ems-flasher does allow you to add/remove a single ROM in a bank, although I haven't peeked at the code so I couldn't tell you that it wasn't just automatically reflashing the entire bank.

Looking at the code, it lets you remove a single ROM. The problem is that this could lead to fragmentation (when you write a ROM, it searches for available space between the ROMs, and it could become sparse). Still, it is a good starting point, I'll think how to integrate it in the UI.
Then I'll have a look at MottZilla's menu to see if I can do something about multiple SAVs (it was not on my priority list since I mainly use EMS cart with LSDj and I know that lsdj SAVs take up all the available SRAM space, so even with MottZilla's menu you can't have more than one SAV if you use LSDj).

Offline
Naptown

Ok good luck! Please report back and let us know what you find out. Thanks for all your hard work!

Offline
France

Thank you rbino for the ems-qart program, it works really well. At the moment I was using the Android app which is cool too (and can backup individual lsdj songs), but I appreciate to be able to handle the sav and roms from my linux computer too!

The ems-flasher with multi-rom is great too even if I'd prefer to use ems-qart, except for multi roms.

You can grab the menu.gb or menu.gbc rom from here, concatenate the roms you want onto it

is there a way to concatenate roms from a command line (without flashing to cart)? I've tried with "cat menu.gb rom1.gb rom2.gb > myrom.gb" and I've transfered myrom.gb. I've got the list of the roms / games on it, but whenever I try to launch on of them, the screen remains blank. Otherwise ems-flasher works fine if you send the roms directly on the cart, from the command line (some doesn't work though, but might work if you transfer them with a new set of roms).

Offline
garvalf wrote:

is there a way to concatenate roms from a command line (without flashing to cart)? I've tried with "cat menu.gb rom1.gb rom2.gb > myrom.gb" and I've transfered myrom.gb. I've got the list of the roms / games on it, but whenever I try to launch on of them, the screen remains blank

It's not possible to simply cat the ROMs together because their offset inside the final ROM has to be aligned to the ROM size (apparently because of a limitation in the EMS cart, see here).
Multi-ROM support will arrive asap, I'm thinking about how to integrate this new functionality in the current UI in a sane way before starting to write the code, if someone has suggestions they're welcome!

Offline
Italy

This is great! My old windows laptop is about to die and I was afraid of not being able to flash the carts anymore. Will have a go at the concatenation thing. So just so I get this right, I do have to use that if I want to have multiple ROMS available on the cart, don't I?

@rbino: if you need some help UI wise, I'd be happy to help, designing UIs is what I do in my life smile but I'll be away for a couple of weeks now, just so you know...

Offline
France

Thank you for the explanation. It'll be great if ems-qart can handle multi-rom. I noticed far below the limit of 64 Mo the ems-flasher complains about full cart when I transfert gbc roms. Around 4 Mo I can't send more... I don't know for classic .gb how many roms it can get before reaching the limit.

Anyway, for the ems-qart UI (which is great), it would make sense to have a smaller cart image, and add extra information below. Since there won't be like 60 roms in a cart (I guess), you could use scroll bars. Adding multiple roms could be also below the left image.
I've made a quick and dirty mockup:

Also by default on my system, the ems-qart window is quite huge (1050 px wide, 700 px high). I noticed also the images are probably in svg because if I make the window bigger, they can grow. So maybe the window could be more like 800x600 to fit on smaller screens (maybe it's the case, it depends on resolution?), or at least be able to reduce the size. Maybe it's also this size because my fonts are quite big. In this case, the "bank x Bank 1 [] bank 2" field could maybe wrap in the line below (even if it would look less nice this way)

Offline
rumpelfilter wrote:

Will have a go at the concatenation thing. So just so I get this right, I do have to use that if I want to have multiple ROMS available on the cart, don't I?

Actually, the concatenation thing doesn't work so simply, it requires the cart to be aligned to their size

rumpelfilter wrote:

@rbino: if you need some help UI wise, I'd be happy to help, designing UIs is what I do in my life smile but I'll be away for a couple of weeks now, just so you know...

I'd be happy to accept your help! I am by no means a UI expert, and the nice thing about working with QML and Qt is that is fairly easy to translate a well designed mockup in a working UI.

Offline
garvalf wrote:

I noticed far below the limit of 64 Mo the ems-flasher complains about full cart when I transfert gbc roms. Around 4 Mo I can't send more... I don't know for classic .gb how many roms it can get before reaching the limit.

Keep in mind that the cart memory is 64 Mega_BITS_, divided in 2 banks (32 Mega_BITS_ each), and 32 Megabits == 4 Megabytes, so the limit makes sense.

garvalf wrote:

Also by default on my system, the ems-qart window is quite huge (1050 px wide, 700 px high). I noticed also the images are probably in svg because if I make the window bigger, they can grow. So maybe the window could be more like 800x600 to fit on smaller screens (maybe it's the case, it depends on resolution?), or at least be able to reduce the size. Maybe it's also this size because my fonts are quite big. In this case, the "bank x Bank 1 [] bank 2" field could maybe wrap in the line below (even if it would look less nice this way)

Yes, the windows is big to accomodate the horizontal radio buttons. I can think about putting them vertically (one above the other) so I can make the window a little smaller.
Anyway, your mockup is a good starting point, but lacks some interactions. For example: how can a user delete a single cart on the rom?

Offline
Italy

Actually, the concatenation thing doesn't work so simply, it requires the cart to be aligned to their size

Yes I read that and that " The menu only supports ROMs whose size is a power of two." but I'm not sure I understand the practical implications of this. does it mean that if I have a 33Kb ROM I can't concatenate it? Also, what means "aligned" in this context? Sorry if these are dumb questions, but I'm not really into coding, so some of this does sound a bit alien to me smile

I'd be happy to accept your help! I am by no means a UI expert, and the nice thing about working with QML and Qt is that is fairly easy to translate a well designed mockup in a working UI.

cool, yes I'd be willing to give it a go!

Offline
Medina, Ohio
rumpelfilter wrote:

Yes I read that and that " The menu only supports ROMs whose size is a power of two." but I'm not sure I understand the practical implications of this. does it mean that if I have a 33Kb ROM I can't concatenate it? Also, what means "aligned" in this context?

Only supporting ROMS that are the size of a power of two enables the ability to calculate the end of the bits very easy and quick so it can copy the contents easier rather than having to search for the end of the bits. Info is stored in chunks of data on the hard drive that are all powers of 2 wide. Files start at a chunk start. If the file does not end right before the start of a new chunk, there is padding space between it and the new file.

Basically it can just be like hey this file is 2^4 units big. S = x = file_location. E = S + 2^4. Copy bits between S and E to some place.

Aligned means the bits are physically aligned to start at a power of two in the RAM. Basically, the way memory works it is easiest and most efficient to work with powers of two.

Hope I explained this okay, might be a little wrong but thats the general idea I believe.