Denial

As part of my ongoing work on JVic libGDX, I'm planning to use an approach similar to Beebdroid where it presents a list of game icons and allows the user to select games to download automatically. This will save having to manually move files in to the app's data folders. So my question is: What are people's recommendations for the best site for the emulator to integrate with for this purpose?

I'm looking for something that is going to be around for a long time.

This caught my eye when I was searching a few night's back:

https://archive.org/details/Commodore_V ... 2012_04_23

It has the following collection:

http://ia801603.us.archive.org/zipview. ... _04_23.zip

archive.org is likely to be around for a long time, so it seems like a good choice. Individual games can be downloaded from the collection.

I know we also have some games here:

http://www.zimmers.net/anonftp/pub/cbm/vic20/

and that the web.archive.org snapshots of the above include the game files, so might be another good long term option maybe to fall back on if the main site goes down. Not sure how extensive it is though. The TOSEC collection appears to be bigger as it's intention appears to be to preserve as much as it can.

Are there other options for downloading individual games?

I think zimmers probably is yor best option, because it has been there forever, the files are unpacked and ready to run. Most programs and carts are in there...

for a vic20 emu i'd just pack it with a megacart or ultimem image - then you have pretty much everything anyway

I was considering that at one point. If I eventually put it up on Google Play, would I get away with packaging the games with the emulator? The other emulators avoid this but have we reached a point now where no one cares?

GameBase20 is going to have quite a few games not on TOSEC or Zimmers.

Look here too http://www.thefuturewas8bit.com/media/w ... lection.7z

I'd like to come up with a more academic argument: "oursourcing" the files increases the traffic to those storage sites, and shifts the burden to a party not involved with your emulator. Of course you could always run into the issue, that one of these sites suddenly ceases operation, rendering your emulator+database non-functional.

IMO, keeping the whole package self-contained (like GB20 does) is a more sustainable approach.

However, with the VIC-20 there is still active (game) development, so you cannot expect closure anytime soon - which means the package should also allow for user defined entries into the database.

And with pure (Win)VICE at hand, you just don't bother. It's the emulated equivalent of the machine that matters, you need to know anyway what kind of memory expansions are necessary for each game as you run into the same problems when using the real iron. And then you quickly get to the point, that only two dozen or so games are played most of the time, and they are then collected on a few disk images, along with boot loaders. Or you are one of the lucky ones, who own a Mega-Cart.

Some very good points. I'm aware that I'll need access to additional meta data for each game, such as the machine type (PAL/NTSC), memory expansion, the name and path to the game files, a path to an icon representing the game (whether that be a small screen shot or game cover or something else), and a display name, and sometimes a command to auto run, such as a SYS command. I was thinking of having this meta data as a json file within the emulator, but that doesn't allow for the addition of new games. So you've started me thinking that what I really need is my own database hosted somewhere on the net. It could contain both the meta data and the game files. It could provide a data entry form for configuring new games. It could even hold comments on the status of support for the game. If I host it on something that isn't going to go away any time soon, it would hopefully serve the purpose. If it does die one day, I guess I'd need to move it somewhere else (assuming I had backups), but that would be my problem rather than the maintainer of another collection.

Edit: Or I could put most of it in the emulator package and provide the ability to load additional entries from my database hosted on the net somewhere.

lance.ewing wrote:Some very good points. I'm aware that I'll need access to additional meta data for each game

Not if you include Prg Starter functionality into your app. Then the user could either provide a web address of a file, or open a downloaded file, and it would be started with the correct memory configuration automatically. Is your app to be open source or closed source? Would you be interested in having the prg starter source code? It's written in vb.net.

It's a work in progress, but the emulator is already open source. It is written in Java and the code is currently stored on a public github repo. I'm using a Java library called libGDX that allows apps written in Java to be built for Android, iOS, desktop, and HTML5. The main focus is Android at the moment, since I don't have a mac, etc. required for building the iOS version, but the idea is to get it to a stable Android release on Google Play and then release it for iOS.

JVic already uses a certain degree of auto recognition for memory configuration. If the first two bytes of a .PRG file represent a known VIC 20 load address then it can tell from that address if it was an unexpanded game, 3K game, or 8K+. In the later case the emulator just gives it 24K, which to be honest is what I did on the real machine. I had a single custom built cartridge that had a switch that allowed 0K, 3K and 24K to be chosen. So if a game required at least 8K, I just set the memory cartridge to 24K.

The cartridge logic in JVic is a bit different. At the moment JVic is told whether it is a cartridge or not, but I could probably work it out based on the first two bytes not being one of the expected load addresses for a non-cartridge program. It then becomes a question of where to load the cartridge file. Some are multipart and I've seen that sometimes the extension indicates the load address. I've also seen that cartridge files sometimes put the load address in to the first two bytes.

Do cartridge games ever add additional RAM? Or do they always use the unexpanded RAM for their purposes? If there were particular cartridges that would only work without expanded RAM, and others that will only work with additional RAM, then JVic wouldn't handle that without additional meta data. At the moment JVic assumes unexpanded RAM for all cartridge games.

The choice between NTSC and PAL is also something it wouldn't be able to detect. And I'd like to be able to display a full display name for each game, along with an icon of some sort, and be able to autorun games that require a certain SYS command, such as the Scott Adams games. The emulator doesn't currently support .TAP or .D64 files, but eventually I'd get around to supporting those.

I haven't used Prg Starter before. Are you able to list for me what of the above desired features it could provide?

Please visit the link in my signsture for info about prg starter.

It would probably just be tool carts that would benefit from additional ram.

Ntsc/pal would just be a very few games where it would be an issue. I would probably run everything in pal.

All cart files from zimmers are just normal prg files with a load adress, and in my oppinion, that's prefered way for vic-20 as you can run them on a real vic without troubles that way.

Boray wrote:Is your app to be open source or closed source? Would you be interested in having the prg starter source code? It's written in vb.net.

Even if he wouldn't then I would love to see it. What's the approach? A database or direct file inspection?

I think that since were in the 21st century gamebase 20 or similar should be online. I did a prototype website a while ago converting the database to sql server and asp.net. It could include the ability to download or hotlink directly to matt Dawson's excellent JavaScript emu.

Tom wrote:

Boray wrote:Is your app to be open source or closed source? Would you be interested in having the prg starter source code? It's written in vb.net.

Even if he wouldn't then I would love to see it. What's the approach? A database or direct file inspection?

PRG Starter analyzes the file, with the starting address, different basic versions, usage of different chip addresses in the program...

Boray wrote:PRG Starter analyzes the file, with the starting address, different basic versions, usage of different chip addresses in the program...

Cool. I am one of the many that wander through here having a bit of fun writing an emulator but my underlying position is: using emulators is far too much hassle. They should just work. So I'd be very keen to get the PRG starter algorithm implemented in my little project, as inconsequential as it'll be.

I'll come back with screenshots when I can, as I appreciate the source is not inherently open.