Jump to content
IGNORED

Skunkboard Update


Tursi

Recommended Posts

 

Well, you could upload the memory dumper on this page: http://www.mdgames.de/jag_eng.htm

 

Then browse to the RAM :)

Good idea. :) I did that by issuing "jcp -6 memdmp11.abs" and I browsed the memory before and after $C00000. What I am finding is that all memory above $C00000 (not just the first 8KB) is cycling through some sort of pseudo-random data pattern that repeats every 64 refreshes. The repeating pattern is not tied to a memory location. In other words, if I just bounce the memdmp screen back and forth between two ROM locations above $C00000, it will keep changing the data displayed for these two locations but eventually repeat every 64 times.

 

The memory prior to $C00000 does not cycle; it returns the same data every time you refresh, just as expected since it is in the ROM space.

Link to comment
Share on other sites

I found it silk screened on the board (the back of my cart is open partially to fit the usb/header pins (I really should desolder those)... I have a revision 2 so I'll need to do the board mod.

 

So the lovely vinyl label that was provided to me will be destroyed. Anyone have or willing to make me another 2 labels?

Link to comment
Share on other sites

Good idea. :) I did that by issuing "jcp -6 memdmp11.abs" and I browsed the memory before and after $C00000. What I am finding is that all memory above $C00000 (not just the first 8KB) is cycling through some sort of pseudo-random data pattern that repeats every 64 refreshes. The repeating pattern is not tied to a memory location. In other words, if I just bounce the memdmp screen back and forth between two ROM locations above $C00000, it will keep changing the data displayed for these two locations but eventually repeat every 64 times.

 

The memory prior to $C00000 does not cycle; it returns the same data every time you refresh, just as expected since it is in the ROM space.

The system was never intended to JCP -6 to RAM, from your symptoms it probably did not switch the system into 6MB mode and so you're reading the HPI registers. If you aren't doing -6F then all bets are off on that respect. :)

 

But if that tool lets you write memory too, you should be able to turn on 6MB mode directly using the two writes I gave earlier. Otherwise, maybe you can insert them into the code? ;)

  • Like 1
Link to comment
Share on other sites

I found it silk screened on the board (the back of my cart is open partially to fit the usb/header pins (I really should desolder those)... I have a revision 2 so I'll need to do the board mod.

 

So the lovely vinyl label that was provided to me will be destroyed. Anyone have or willing to make me another 2 labels?

Make your own. :) Here's the file I used.

 

SkunkboardLogo.zip

 

I don't remember the company I ran them off at (and I wouldn't recommend them anyway as my Sinistar sticker arrived damaged and they wouldn't even talk to me), but I just found them with a web search for 'vinyl stickers'. ;) These days I use VistaPrint for most crap. ;)

Edited by Tursi
  • Like 2
Link to comment
Share on other sites

Hello!

 

Good idea. :) I did that by issuing "jcp -6 memdmp11.abs" and I browsed the memory before and after $C00000. What I am finding is that all memory above $C00000 (not just the first 8KB) is cycling through some sort of pseudo-random data pattern that repeats every 64 refreshes. The repeating pattern is not tied to a memory location. In other words, if I just bounce the memdmp screen back and forth between two ROM locations above $C00000, it will keep changing the data displayed for these two locations but eventually repeat every 64 times.

 

The memory prior to $C00000 does not cycle; it returns the same data every time you refresh, just as expected since it is in the ROM space.

 

I have just uploaded a Skunkboard-specific version of my tool here http://www.mdgames.de/Memdmp12.zip

 

This version now supports switching between Bank0, Bank1 and the 6MB (sorry for the joypad-key-mapping), i tried it out with an updated formerly Rev2-board.

 

Interestingly you will see the behaviour that Carl has described when you browse the $c00000 adress area, but only as long you are just switching between Bank0 and Bank1. As soon as you have once switched to the 6MB-mode you will always see the first 2MBs of Bank1 shown in the browser at this adress area.

 

Kind regards

Matthias

  • Like 5
Link to comment
Share on other sites

Thanks, Matthias! Results using the latest version of the tool:

 

I see all $FFFF values from $c00000 to $c02000. Correct ROM data occurs before $c00000 and after $c02000, but with an interesting twist: the data which should have displayed at $c00000 instead displays at $c02000. So instead of just losing the 8KB of data and picking up where it left off, I am seeing the data shifted by 8KB.

Link to comment
Share on other sites

Hello!

 

So is 6MB mode completely debugged? Because I am testing my CGE 5th anniversary slideshow which is approximately 4.6MB in size, and I am finding that the last 4 pics in the ROM image are corrupted, and they would be the ones bleeding over the 4MB boundary.

 

 

I think this is caused by DetermineFileInfo() in JCP.C, but only if your file has the extension ".ROM". As Tursi said, the 6MB-file will be split into 2 parts, and therefore the second part will also be processed by DetermineFileInfo(), which will alter the base address to 0x802000 for headerless "files" if the file extension is ".ROM".

 

Regards

Matthias

  • Like 1
Link to comment
Share on other sites

Interestingly you will see the behaviour that Carl has described when you browse the $c00000 adress area, but only as long you are just switching between Bank0 and Bank1. As soon as you have once switched to the 6MB-mode you will always see the first 2MBs of Bank1 shown in the browser at this adress area.

$C000000 starts the HPI bus interface to the USB controller, when you switch to 6MB mode it disables that map. So when you are reading up in that area, you're reading the HPI space which, in turn, is reading the microcontroller's memory space. :)

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

Matthias, I just noticed your comment on DetermineFileInfo(). Thanks for that catch -- I couldn't reproduce the issue, but my 6MB file is a COF! With that information I was able to reproduce the issue and so prove the fix.

 

I also spent some time tonight and integrated the firmware update into JCP, like the old rev 1 had. I kept the rev 1, so that meant I had to add detection of which board you needed. Interestingly, my rev 1 board still had version 1.01.00 on it, which had a lot of problems with continuing to run after a program was uploaded, thwarting my version detection. For boards that old I had to add a force option, but otherwise it works now on all revisions of Skunkboard, updating to either 1.02.04 (the last release of that) or 3.00.02 (which is the release I just did recently). Rev 2 boards won't be hurt by the Rev 3 BIOS, though of course they lose the high voltage programming option. (A hardware mod is required to make it safe, however, as I will note every time I mention this.)

 

Anyway, here's the new JCP, which includes the finally fixed 6MB mode upload, even for headerless files named ROM, as well as built-in firmware update for Rev 2 and Rev 3 boards. The two new flash options (both optional) are "-!u" to force the old style rev 1 board update (I needed that for my rev 1.01.00 board), and "-fu" to force the update even if it detects you already have it (although I can't see how it would be useful if the board works well enough to take it, I didn't want to lock it out.) Most of the time you'll just use "-u" as per normal.

 

Enjoy!

 

jcp2.zip

  • Like 4
Link to comment
Share on other sites

Matthias, I just noticed your comment on DetermineFileInfo(). Thanks for that catch -- I couldn't reproduce the issue, but my 6MB file is a COF! With that information I was able to reproduce the issue and so prove the fix.

 

I also spent some time tonight and integrated the firmware update into JCP, like the old rev 1 had. I kept the rev 1, so that meant I had to add detection of which board you needed. Interestingly, my rev 1 board still had version 1.01.00 on it, which had a lot of problems with continuing to run after a program was uploaded, thwarting my version detection. For boards that old I had to add a force option, but otherwise it works now on all revisions of Skunkboard, updating to either 1.02.04 (the last release of that) or 3.00.02 (which is the release I just did recently). Rev 2 boards won't be hurt by the Rev 3 BIOS, though of course they lose the high voltage programming option. (A hardware mod is required to make it safe, however, as I will note every time I mention this.)

 

Anyway, here's the new JCP, which includes the finally fixed 6MB mode upload, even for headerless files named ROM, as well as built-in firmware update for Rev 2 and Rev 3 boards. The two new flash options (both optional) are "-!u" to force the old style rev 1 board update (I needed that for my rev 1.01.00 board), and "-fu" to force the update even if it detects you already have it (although I can't see how it would be useful if the board works well enough to take it, I didn't want to lock it out.) Most of the time you'll just use "-u" as per normal.

 

Enjoy!

 

attachicon.gifjcp2.zip

i appear to get an error when running this

the previous jcp works ok

 

i have tried it in widows and command prompt and both give the same error

post-18126-0-43674800-1468145055_thumb.png

Link to comment
Share on other sites

hmm.. I didn't change any build settings since the last one. Is it working for anyone else? MSDN suggests a DLL conflict is the usual cause, but I don't have a second machine up to test on at the moment. (What version of Windows?)

Link to comment
Share on other sites

hmm.. I didn't change any build settings since the last one. Is it working for anyone else? MSDN suggests a DLL conflict is the usual cause, but I don't have a second machine up to test on at the moment. (What version of Windows?)

windows 7 64 bit

Link to comment
Share on other sites

I can corfirm omf´s issues with the previous JCP.exe on a Windows XP Home netbook, see screenshot #1.

 

post-10054-0-20514400-1468304669_thumb.jpg

 

Then I tried the new JCP.exe dated July 10 (V02.04.02) and it cured the issue, see screenshot #2.

 

post-10054-0-88823100-1468304501_thumb.jpg

 

 

My Skunkboard is a Rev. 2, unmodified, boot version 02.00.05.

 

 

Edited by jaguar_fan
  • Like 1
Link to comment
Share on other sites

where might i buy a new skunkboard or will there ever be another run? tracking one down via trade or used seems like it might be more of a challenge but i am interested in this

 

Not to mention the BS price they tend to sell for of $399 - $599 - I'd love to get another one but not for 5x the price

  • Like 3
Link to comment
Share on other sites

  • 3 weeks later...

where might i buy a new skunkboard or will there ever be another run? tracking one down via trade or used seems like it might be more of a challenge but i am interested in this

 

I never use mine - I might be more interested in a trade than cash though. What's a realistic price for the skunkboard these days?

Link to comment
Share on other sites

  • 1 month later...

Make your own. :) Here's the file I used.

 

attachicon.gifSkunkboardLogo.zip

 

I don't remember the company I ran them off at (and I wouldn't recommend them anyway as my Sinistar sticker arrived damaged and they wouldn't even talk to me), but I just found them with a web search for 'vinyl stickers'. ;) These days I use VistaPrint for most crap. ;)

 

 

Finally updated my Rev 2 Skunkboard, Managed to peel back the vinyl sticker without damaging it so it looks good as new. Thanks for the easy to read guide on the power fix too.

Link to comment
Share on other sites

  • 11 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...