Looking for Warpspeed source code
Robert Bernardo
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?
Thanks for any help,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
Rodolfo Leal
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
archon
"Rodolfo Leal" <cpul...@uymail.com> wrote in message
news:d8d8fcb5.03121...@posting.google.com...
You wouldn't have the rom to be used in an emulator would you?
Rodolfo Leal
> You wouldn't have the rom to be used in an emulator would you?
Archon,
No. I don't have it. But with a little of luck I'm on the way to
get a Warpspeed cartridege soon. Maybe then I'll have the ROM too.
Regards,
Rodolfo Leal
RajW
wrote:
Here you go:
http://www.c64.us/cbmfiles/roms/C128WarpSpeedV1-1987.bin
http://www.c64.us/cbmfiles/roms/C128WarpSpeedV2-1987.bin
Enjoy!
/*Raj*/
RajW
>http://www.c64.us/cbmfiles/roms/C128WarpSpeedV1-1987.bin
>http://www.c64.us/cbmfiles/roms/C128WarpSpeedV2-1987.bin
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.
Enjoy!
/*Raj*/
iAN CooG
> 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
RajW
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.
http://markus.brenner.de/cartridge/
This will get you going in the right direction.
/*Raj*/
iAN CooG
> are not disassembling the code from the correct start location.
^_^;;; err...
I'm not SO dumb, and I think I know some C64 assembly :P
This is a partial hex dump of C128WarpSpeedV1-1987.bin
00000000: 52 1B 80 52-44 5A 20 4D-20 BF EC A4-3A F7 52 20
00000010: 20 A8 80 20-83 A4 AD 20-88 22 01 1C-20 A8 80 20
00000020: AA 45 C1 17-62 20 48 88-20 39 88 20-E1 EB CA A0
00000030: 32 AA 3F 32-1A 32 AA 0F-AA 32 32 AA-32 AA 27 43
00000040: 06 98 BB 03-25 20 4A 92-90 18 BB 03-2A 1E 22 81
00000050: CA 1A 60 B4-00 98 81 A4-B8 81 C1 FC-88 B4 7E E1
00000060: 23 AA 45 20-98 7A 20 A2-20 F5 A4 A4-9B 73 08 E2
00000070: 73 08 B4 8F-9D 89 42 B8-5D 20 90 98-FF 62 20 A2
00000080: A4 89 E1 1A-C0 93 E1 18-D7 52 4B 90-B4 A7 94 76
and C128WarpSpeedV2-1987.bin
00000000: 52 24 80 52-44 5A 20 4D-AA A0 9A 90-A4 00 A0 A0
00000010: A1 30 DD 01-20 B8 80 20-20 82 83 20-1C 30 DD 01
00000020: 7C 90 A7 96-C1 17 62 62-5C 88 62 62-88 20 78 88
00000030: 3D 88 62 32-3F 32 AA 89-AA 0F 32 AA-32 AA 05 32
00000040: 18 BB 03 60-1E 22 81 04-32 90 E1 15-CA 20 E1 10
00000050: FF 62 B4 81-88 20 93 93-89 A1 D7 62-7A B4 7E E1
00000060: 7A 20 63 B3-00 20 B8 FF-E0 0E C1 F9-25 90 B8 6C
00000070: A2 E1 07 AA-62 A6 AA 08-25 90 20 FC-00 94 7A E1
00000080: 52 59 90 B8-2A 94 61 A0-76 A4 10 94-A7 FF 83 20
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).
Bah. It's not so important anyway :)
Robert Bernardo
> 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.
Truly,
Mikael Holm
> news:d8d8fcb5.03121...@posting.google.com...
>
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.
// Mikael
Ruud Baltissen
> 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.
--
___
/ __|__
/ / |_/ Groetjes, Ruud
\ \__|_\
\___| http://Ruud.C64.org
RajW
On 15 Dec 2003 03:36:31 -0800, Ruud.Ba...@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)
/*Raj*/
Jason Petersen
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?
--
Jason
Ruud Baltissen
> If that were true, then if I burned the chip back to an EPROM it
> wouldn't work. Correct?
No. You burn the new EPROM with data you just read ie. you make an
exact copy of the original one. So if the original works, why wouldn't
the copy?
What probably is confusing you is the fact that the developers had to
encode the original BIN file in a way so that the cartridge could use
it.
If you have such a cartridge, just try to find out if indeed lines
have been swapped.
RajW
On 16 Dec 2003 03:55:06 -0800, Ruud.Ba...@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).
/*Raj*/
RajW
wrote:
>If you have such a cartridge, just try to find out if indeed lines
>have been swapped.
(update)
Yep... you were absolutely correct... I just finished tracing the data
lines and they are all over the place. :p
Chip D0 -> Cartridge pin 17/D4
Chip D1 -> Cartridge pin 18/D3
Chip D2 -> Cartridge pin 20/D1
Chip D3 -> Cartridge pin 21/D0
Chip D4 -> Cartridge pin 19/D2
Chip D5 -> Cartridge pin 16/D5
Chip D6 -> Cartridge pin 15/D6
Chip D7 -> Cartridge pin 14/D7
I'm working on the address lines now.
/*Raj*/
RajW
wrote:
>If you have such a cartridge, just try to find out if indeed lines
>have been swapped.
Well... that was just plain ugly! Here is how the data and address
lines are connected on the Warpspeed cartridge:
Chip pin --- Cartridge port
A0 --------- Y/A0
A1 --------- X/A1
A2 --------- V/A3
A3 --------- U/A4
A4 --------- S/A6
A5 --------- P/A8
A6 --------- M/A10
A7 --------- L/A11
A8 --------- N/A9
A9 --------- R/A7
A10 -------- W/A2
A11 -------- T/A5
A12 -------- J/A13
A13 -------- K/A12
A14 -------- VCC
D0 --------- 17/D4
D1 --------- 18/D3
D2 --------- 20/D1
D3 --------- 21/D0
D4 --------- 19/D2
D5 --------- 16/D5
D6 --------- 15/D6
D7 --------- 14/D7
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!)
/*Raj*/
Marko Mäkelä
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];
static unsigned char image[1 << 19];
int
main (int argc, char** argv)
{
unsigned i;
for (i = 256; i--; )
databus[i] =
MVBIT (i, 0, 5) |
MVBIT (i, 1, 6) |
MVBIT (i, 2, 7) |
MVBIT (i, 3, 4) |
MVBIT (i, 4, 3) |
MVBIT (i, 5, 2) |
MVBIT (i, 6, 0) |
MVBIT (i, 7, 1);
for (i = 0; i < sizeof image; i++) {
int c = getchar ();
if (c == EOF)
break;
else
image[MVBIT (i, 0, 17) |
MVBIT (i, 1, 18) |
MVBIT (i, 2, 16) |
MVBIT (i, 3, 15) |
MVBIT (i, 4, 12) |
MVBIT (i, 5, 7) |
MVBIT (i, 6, 6) |
MVBIT (i, 7, 5) |
MVBIT (i, 8, 4) |
MVBIT (i, 9, 3) |
MVBIT (i, 10, 2) |
MVBIT (i, 11, 1) |
MVBIT (i, 12, 0) |
MVBIT (i, 13, 13) |
MVBIT (i, 14, 14) |
MVBIT (i, 15, 11) |
MVBIT (i, 16, 8) |
MVBIT (i, 17, 9) |
MVBIT (i, 18, 10)] =
databus[(unsigned char) c];
}
return fwrite (image, 1, sizeof image, stdout);
}
RajW
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?
> else
> image[MVBIT (i, 0, 17) |
> MVBIT (i, 1, 18) |
> MVBIT (i, 2, 16) |
> MVBIT (i, 3, 15) |
> MVBIT (i, 4, 12) |
> MVBIT (i, 5, 7) |
> MVBIT (i, 6, 6) |
> MVBIT (i, 7, 5) |
> MVBIT (i, 8, 4) |
> MVBIT (i, 9, 3) |
> MVBIT (i, 10, 2) |
> MVBIT (i, 11, 1) |
> MVBIT (i, 12, 0) |
> MVBIT (i, 13, 13) |
> MVBIT (i, 14, 14) |
> MVBIT (i, 15, 11) |
> MVBIT (i, 16, 8) |
> MVBIT (i, 17, 9) |
> MVBIT (i, 18, 10)] =
> databus[(unsigned char) c];
And then reduce this 16 bits also? Would this be the correct syntax?
bitchanger < romfile.bin > fixed.bin
Thanks,
/*Raj*/
iAN CooG
> 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)
/*--------------------*/
#include <stdio.h>
static unsigned char databus[256];
static unsigned char image[1 << 14];
#define MVBIT(i,from,to) (((i) & 1 << (from)) ? 1 << (to) : 0)
int main (int argc, char** argv)
{
unsigned i;
FILE *hin,*hout;
if(argc<3)
return 1;
hin =fopen(argv[1],"rb");
if(!hin)
return 2;
hout=fopen(argv[2],"wb");
if(!hout)
return 3;
for (i = 255; i; i--)
databus[i] =
MVBIT (i, 0, 4) |
MVBIT (i, 1, 3) |
MVBIT (i, 2, 1) |
MVBIT (i, 3, 0) |
MVBIT (i, 4, 2) |
MVBIT (i, 5, 5) |
MVBIT (i, 6, 6) |
MVBIT (i, 7, 7);
for (i = 0; i < sizeof image; i++) {
int c = getc(hin);
if (c == EOF)
break;
else
image[MVBIT (i, 0, 0 ) |
MVBIT (i, 1, 1 ) |
MVBIT (i, 2, 3 ) |
MVBIT (i, 3, 4 ) |
MVBIT (i, 4, 6 ) |
MVBIT (i, 5, 8 ) |
MVBIT (i, 6, 10) |
MVBIT (i, 7, 11) |
MVBIT (i, 8, 9 ) |
MVBIT (i, 9, 7 ) |
MVBIT (i, 10, 2 ) |
MVBIT (i, 11, 5 ) |
MVBIT (i, 12, 13) |
MVBIT (i, 13, 12) ] = databus[(unsigned char) c];
}
return fwrite (image, 1, sizeof image, hout);
}
/*--------------------*/
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 CooG/HokutoForce+TWT---=[]=-
Is that an XT? Oh, you're running WindowsXP.
RajW
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)
And all solved in 20 posts! Whoo! Hoo!
/*Raj*/
RajW
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?
/*Raj*/
Nathan Smith
"RajW" <r...@intelc64.net> wrote in message
news:viu1uvct71k1o9kei...@4ax.com...
>
> 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.
iAN CooG
> 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)
>
> And all solved in 20 posts! Whoo! Hoo!
Cool indeed. I've included this text in the readme, zipped all files and
put them on my site, also the original sources provided by Rodolfo Leal.
http://iancoog.altervista.org/
http://iancoog.altervista.org/C/WarpSpeedCRT/C128WarpSpeed.zip
http://iancoog.altervista.org/C/WarpSpeedCRT/WarpSpeed_source.zip
iAN CooG
> 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.
In a first attempt, the v2.0 decrypted was 32kb like the raw, but
examining it I saw it was just 16Kb repeated 2 times (0-3fff equal to
4000-7fff)
> same. Why the size decrease?
I've set the image array 1<<14 (16Kb); try with
static unsigned char image[1 << 15];
and
image[MVBIT (i, 0, 0 ) |
MVBIT (i, 1, 1 ) |
MVBIT (i, 2, 3 ) |
MVBIT (i, 3, 4 ) |
MVBIT (i, 4, 6 ) |
MVBIT (i, 5, 8 ) |
MVBIT (i, 6, 10) |
MVBIT (i, 7, 11) |
MVBIT (i, 8, 9 ) |
MVBIT (i, 9, 7 ) |
MVBIT (i, 10, 2 ) |
MVBIT (i, 11, 5 ) |
MVBIT (i, 12, 13) |
MVBIT (i, 13, 12) |
MVBIT (i, 14, 14) ] = databus[(unsigned char) c];
to decrypt all the 32Kb.
BTW mcart does not accept anything else than a 16Kb binary to build the
WarpSpeed CRT. I assume Markus Brenner knows what he says ;)