Hello, C= friends, I have a person who is interested in studying the source code of the Warpspeed cartridge. Though the co-developer, Marty Franz, released the code some time ago at his website, it is no longer there (in fact, the link no longer points to his website but to something about fishing!). Does anybody have that source code? Did anybody go to Marty's website and grab that code before the site disappear?
Hello Robert, I have the file with the source code or at least the file that was on the site. It's big, around 2 MB compressed. I'm willing to share it if you want it.
> Hello Robert, > I have the file with the source code or at least the file that was > on the site. It's big, around 2 MB compressed. I'm willing to share it > if you want it.
> Regards, > Rodolfo Leal
You wouldn't have the rom to be used in an emulator would you?
RajW <r...@intelc64.net> wrote: > Just an FYI... those files are RAW chip dumps. I pulled the chips off > the boards and read them out with an EPROM reader/programmer.
I've examined both, no 6502 code in them, they seem 2 files filled with rubbish, at least for a 6502 disassembler. Any way to convert to something readable?
-- -=[]=---iAN CooG/HokutoForce+TWT---=[]=- Boost the performance of your PC: DEL C:\WINDOWS
On Sun, 14 Dec 2003 07:50:21 GMT, "iAN CooG" <ianc...@despammed.com> wrote:
>I've examined both, no 6502 code in them, they seem 2 files filled with >rubbish, at least for a 6502 disassembler. Any way to convert to >something readable?
ALl I can tell you is that I have burned those images back to EPROMs and they did work, so they do contain valid data. My guess is that you are not disassembling the code from the correct start location.
Markus has created an excellent resource web page for working with cartridges.
No starting address in files, but there's no need, anyway . At a first glance these data seems encrypted. No visible 6502 code.
Markus Brenner's docs are very vague about Warpspeed. They only state to use mdump to dump the rom. Mcart 0.58 produces a Non-working .CRT from v1 binary, and even refuses to read V2 bin (wrong filesize).
On Fri, 12 Dec 2003, Rodolfo Leal wrote: > I have the file with the source code or at least the file that was > on the site. It's big, around 2 MB compressed. I'm willing to share it > if you want it.
Thanks to Rodolfo, I received the source code from him and forwarded it to my programmer friend, will will study the code and possibly incorporate some or all of it into her project.
> You wouldn't have the rom to be used in an emulator would you?
I have dumped my Warpspeed 2.0 and used it under Vice in X64. It doesn't work in X128, apparently due to the implementation of Cartridge handling in the C128-part of the emulator.
So if you think of using VICE 128 and a warpspeed .crt-image, think again... ;-(
If there is another C128-emulator out there that can use .crt-images then please let me know.
But if you like I can e-mail you the dumped cart... Just send me a private e-mail.
> ALl I can tell you is that I have burned those images back to EPROMs > and they did work, so they do contain valid data. My guess is that you > are not disassembling the code from the correct start location.
Another possibility: the data- and/or addresslines are not connected in the right order.
> On 15 Dec 2003 03:36:31 -0800, Ruud.Baltis...@abp.nl (Ruud Baltissen) > wrote:
>>Another possibility: the data- and/or addresslines are not connected >>in the right order.
> If that were true, then if I burned the chip back to an EPROM it > wouldn't work. Correct? But it does work. I'm confused. (sigh)
Perhaps the ROMs are encryped or interleaved, with the decoder in the cartridge hardware? Since you already opened up the cartridge, can you tell us if there are any 74xx logic chips connected to the Warpspeed ROMs?
On 16 Dec 2003 03:55:06 -0800, Ruud.Baltis...@abp.nl (Ruud Baltissen) wrote:
>If you have such a cartridge, just try to find out if indeed lines >have been swapped.
Ok... I'm checking the cartridge right now with an ohm-meter. I'll report back in a little bit. BTW, the glue logic chip on the board is a 74LS109 (dual j-k flip/flop).
Yuck! My brain is to tired right now to "fix/normalize" the raw cartridge dump. Off to go play Planetside and shoot things. (OT:Freekin game uses 800+MB of RAM! Damn!)
RajW> Yuck! My brain is to tired right now to "fix/normalize" the raw RajW> cartridge dump.
It's not that hard. Feel free to adapt the following C program I wrote for shuffling the address and data lines of a 512kB Flash cartridge for the VIC-20. The program reads the shuffled image from stdin and outputs the unshuffled one on stdout. It probably doesn't work on Microsoft operating systems, because they make an artificial distinction between binary and text files, and interpret the CR and LF characters on stdin and stdout as "text" by default.
BTW, in the 4 MB version of the cartridge, I only swapped A0 and A1, because the chip has much nicer pinout (all address and data lines nicely sorted in numerical order).
Marko
#include <stdio.h>
/** Move a bit to another position * @param i the number being shuffled * @param from original bit position * @param to translated bit position * @return the bit in the translated position */ #define MVBIT(i,from,to) (((i) & 1 << (from)) ? 1 << (to) : 0)
/** precomputed table for shuffling the data bus */ static unsigned char databus[256];
On 17 Dec 2003 11:16:31 +0200, Marko Mäkelä <Marko.Mak...@HUT.FI> wrote:
>It's not that hard. Feel free to adapt the following C program I >wrote for shuffling the address and data lines of a 512kB Flash >cartridge for the VIC-20.
I LOVE the people in this newsgroup! :)
>static unsigned char image[1 << 19];
Should change this ^^^ to 15 since I only have 16 bits?
RajW <r...@intelc64.net> wrote: > I LOVE the people in this newsgroup! :)
Me too ^_^
>> static unsigned char image[1 << 19];
> Should change this ^^^ to 15 since I only have 16 bits?
14, 16Kb are the right size of both versions. I made this modified version from Marko source, and it works fine! You have to specify input and output names as parameters (no redirection because in dos/windows redirected files are treated as text and not binary, without setting stdin/stdout to O_BINARY)
On Wed, 17 Dec 2003 23:46:11 GMT, "iAN CooG" <ianc...@despammed.com> wrote:
>RajW <r...@intelc64.net> wrote: >Now these bytes sequences look familiar :) >I've converted both v1 and v2 decrypted bins to CRT with mcart 0.62, >they're working. Team work is good :)
Yes it is! Well orchestrated too if I might add!
This Warpspeed Production brought to you by: -------------------------------------------- Robert Bernardo (Provided me the Warpspeed 2.0 chip to dump) Marko Mäkelä (Coder extraordinaire!) iAN CooG (Code modifier) Ruud Baltissen (Suggested the data & adx lines were rearranged) Raj Wurttemberg (Dumped the chip and traced the data & adx lines)
On Wed, 17 Dec 2003 23:46:11 GMT, "iAN CooG" <ianc...@despammed.com> wrote:
>Now these bytes sequences look familiar :) >I've converted both v1 and v2 decrypted bins to CRT with mcart 0.62, >they're working. Team work is good :)
Ian,
Question... I complied the program on my Linux box with gcc with no problems, but when I run it on the Warpspeed bin file the resulting bin is only 16k. The original is 32k. Just to make sure I wasn't missing something I compiled it under MS VC++ and the results are the same. Why the size decrease?
> On Wed, 17 Dec 2003 23:46:11 GMT, "iAN CooG" <ianc...@despammed.com> > Ian,
> Question... I complied the program on my Linux box with gcc with no > problems, but when I run it on the Warpspeed bin file the resulting > bin is only 16k. The original is 32k. Just to make sure I wasn't > missing something I compiled it under MS VC++ and the results are the > same. Why the size decrease?
> /*Raj*/
Ian's mod was for 16KB ROM, add an extra bit and try again.
RajW <r...@intelc64.net> wrote: > This Warpspeed Production brought to you by: > -------------------------------------------- > Robert Bernardo (Provided me the Warpspeed 2.0 chip to dump) > Marko Mäkelä (Coder extraordinaire!) > iAN CooG (Code modifier) > Ruud Baltissen (Suggested the data & adx lines were rearranged) > Raj Wurttemberg (Dumped the chip and traced the data & adx lines)
