WinVice: unsupported c64 cartridge types

[Harry Potter]

I have WinVice 2.2 and 2.4 and have just decided to continue working on GenCart64, a library for cc65 to allow the creation of ROM cartridges for a C64. So far, it works. However, my current desires are with formats not supported by WinVice. The formats in question are currently Simpn's Basic and WarpSpeed. Are new cartridge formats in consideration? Do other c64 emulators support these cartridge formats?

BTW, I plan to someday implement a cartridge-based codec to compress and decompress BASIC programs. Which format allows the ROM to be disabled except when run?

[Peter Schepers]

> I have WinVice 2.2 and 2.4 and have just decided to continue working
> on GenCart64, a library for cc65 to allow the creation of ROM
> cartridges for a C64. So far, it works. However, my current desires
> are with formats not supported by WinVice. The formats in question
> are currently Simpn's Basic and WarpSpeed. Are new cartridge formats
> in consideration? Do other c64 emulators support these cartridge
> formats?

According to

http://vice-emu.sourceforge.net/vice_7.html#SEC98

both of these CRT's are supported in WinVice.

There's a slew of CRT's defined that I've never gotten around to
including into my FORMATS documentation yet.

PS

[Frank Buss]

Harry Potter wrote:

> BTW, I plan to someday implement a cartridge-based codec
> to compress and decompress BASIC programs. Which format
> allows the ROM to be disabled except when run?

This would be the "Magic Desk" format. I've written a Python script and
a simple loader to create CRT files from any PRG file. Recently I fixed
some bugs with the Basic variable initialization, should be 100%
compatible now:

http://www.frank-buss.de/c64/prg2crt/index.html

Works perfect with the prototype of my new cartridge:

http://www.crazycartridge.org

Feel free to use the assembler and/or Python program for your
compressor, just mention in some readme from where you have it.

--
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss

[Harry Potter]

I thank both of you for your information! :) All that should help.

[Harry Potter]

On Monday, September 23, 2013 4:47:38 PM UTC-4, Frank Buss wrote:
> This would be the "Magic Desk" format.

I looked into my documentation. Magic Desk is a good idea, but if things go well--and I *do* achieve a better compration ratio as I desire--I should only need an 8k cartridge for it; 32k+ should be unnecessary. Such might also be useful for a dirmenu-style GenCart64 demo. DirMenu is another contribution to cc65 I wrote.

[Harry Potter]

I just realized my error. I believe I made a miscommunication here: the cartridge is to contain code that activates during the BASIC program load and save processes, compresses or decompresses the data on-the-fly, then disables itself and returns to BASIC. If I can ever get this to actually work, I might get away with an 8k cartridge. As such, the extra 24k would be wasted. I just looked at my documentation again and didn't find anything useful.

[Bill Buckels]

"Harry Potter" <rose.j...@yahoo.com> wrote:

>I just looked at my documentation again and didn't find anything useful.

Most people have that problem with my documentation too... but at least I
find my own documentation useful. You must write some pretty bad
documentation if you can't even use it yourself:)

Or did I misunderstand you... ??? (Just kidding of course:)

Bill

[Harry Potter]

I want to update my information: the 8k was a guess. I think that the 8k was at best a conservative guess of the needed code size. It *may* be just enough to fit the codec and an interface to the OS. I think that the WarpSpeed format would be better: I get 16k of code space; it only has to be active when used; it could have a read-out of the ratio; it might even allow some fast-load code. The Magic Desk format would do okay by giving 32k, but it would take extra work to switch banks. Of course, I think that the estimate given was based on a cc65 test coder with heavy assembler/zp, a minimized crt0.s file and usage of a simplified text display code (my cbmsimpio library for cc65). I think that removing callmain would save a little because, even when I remove the call in the crt0.s file, I don't cut any bytes from the codec's size. The reason why I keep asking for more optimization techniques is so I can fit the codec in an 8k cartridge--and I didn't know the variety of c64 cartridges at the time. Besides that, if I cut the executable and/or bss data usage by 1k, I have 1k more room for the compression.

BTW, as of now, I don't have a working codec, and when I do, I'll need to be able to interface with the kernel upon startup and override the default LOAD/SAVE routines.