Skunkboard Update

[Tursi]

I was in this code tonight and took the opportunity to fix the 6MB mode glitch. The issue was that the flash code copied the BIOS over to the second bank when writing the second half of the file, corrupting the first 8k at the 4MB point. Updated the code to only bother with that when actually booting bank 2 (testing first), and this seems to work. This code will work on all Rev2 and Rev3 boards, although Rev2 boards that don't have the mod to remove high voltage programming yet will see a slight decrease in performance (and no increase in safety - I recommend the high voltage be removed from Rev2 boards).

 

There was secondly an issue in JCP that was not cleanly booting the code after flashing 6MB, so fixed that. (You could still manually start the program after the flash).

 

Finally, the reason I was in there at all was it was noted that JDB couldn't read cartridge space, so I fixed that and touched up a few little things in Jserve (it's still very hacky though).

 

Rather than make people sift through the huge download, I'm just posting here with just the updated files for your convenience. Enjoy!

 

Skunk302Updates.zip

[TXG/MNX]

Thanx for the fixes.

[Goochman]

Tursi - how do you remove the high voltage from the v2 boards?

[Songbird]

Thank you, Tursi! Awesome support on short notice, and great to bundle several fixes together. I can confirm the ROM visibility works now.

[fille1976]

hi,

 

thx,just updated my version 3 skunkboard.

[Tursi]

Tursi - how do you remove the high voltage from the v2 boards?

My old doc is gone, but I still had the photos so I remade it.

 

Skunkboard Rev 2 High Voltage Mod.pdf

[Fredifredo]

Great ! We have a good dev tool to create 6 MB rom

Now we need to have new carts with 6 MB of rom !

[TXG/MNX]

6MB is nice but still limited I think.

 

I still don't understand why there is still a lack of expansions on the Jaguar like on any other Atari console...

 

Most Atari consoles have freaking advanced hardware like SD, Ethernet (Atari 8-bit) and CPU upgrade / speeders and massive memory upgrades up-to 32MB and multiflash cards with 128MB.

 

I think the jaguar could benefit from a new cartridge, that could add more memory (banked) to the machine, an SD slot and an Ethernet connection (as exampe I would suggest an W5100 this is an embedded chip that has it own TCP/IP stack and is very easy to interface)

Adding all this to one cartridge would make an easy upgrade for people, and it could bring bigger games, or games with better/hq graphics because the memory limitation and CD speed limitation is history.

 

I would support anyone who is capable to design this cart.

[omf]

well as far as i am aware the only rom to use 6 meg was an earlier version of alice moms rescue that was chipped out burnt to the cd version, now alice moms rescue has been compressed down to 4 meg anyway so there isnt much need to have this at the moment anyway in my opinion

[Clint Thompson]

6MB is nice but still limited I think.

 

I still don't understand why there is still a lack of expansions on the Jaguar like on any other Atari console...

 

Most Atari consoles have freaking advanced hardware like SD, Ethernet (Atari 8-bit) and CPU upgrade / speeders and massive memory upgrades up-to 32MB and multiflash cards with 128MB.

 

I think the jaguar could benefit from a new cartridge, that could add more memory (banked) to the machine, an SD slot and an Ethernet connection (as exampe I would suggest an W5100 this is an embedded chip that has it own TCP/IP stack and is very easy to interface)

Adding all this to one cartridge would make an easy upgrade for people, and it could bring bigger games, or games with better/hq graphics because the memory limitation and CD speed limitation is history.

 

I would support anyone who is capable to design this cart.

 

All the other systems are capable of running the memory at full speed though aren't they? Unlike what the Jaguar could do even if expanded so it's crippled. And in instances where the memory does exceed what the unit is capable, a socketed chip can just be replaced like in the XEs with the 4MB memory upgrade.

 

Still would be cool to see what someone could do with a properly utilized 6MB ROM. =)

[Songbird]

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 am using commands such as jcp -6b $802000 to start the program, so I think I'm doing the right things to keep it in 6MB mode...

[Tursi]

The old issue was very straight forward, we were overwriting the first 8k of the 4MB boundary with a copy of the BIOS - deliberately and on purpose so resets would work when bank 2 was selected. I didn't spend a ton of time testing it, and I didn't test any switch combinations... I definitely didn't try launching without it being part of a flash (except for the hold A and press Up on the joypad).

 

I tested it using the 6MB Slide Show I generated ages ago for it, which showed the corruption once it got to the image in question. Looked fine when I ran it... you could also try adding some code to dump the memory at 4MB back to the PC and see if it's corrupted by an attempted BIOS write.. or worse, blank.

 

There was never anything wrong with the 6MB switching, it was just the flasher got confused about whether to write the BIOS or not... without it the Jaguar will hang on reset and needs to be power cycled. So if you're still having trouble, you're probably triggering the write.

 

I guess it's worth noting that with the fix I added, the bank 2 BIOS copy will also overwrite 8k of RAM at 1MB, in case you're loading stuff both to RAM and ROM and then trying to launch. Normally that wouldn't matter but it's good to know.

 

The other thing you can try is just adding the 6MB code to your own program, and starting it as a normal bank 1 program (which shouldn't touch bank 2 and so won't mess with the sometimes BIOS/sometimes code area). This is arguably better if you want to ship for Skunkboard anyway since people won't have to remember to hold A for 6MB mode to start it after the first flash. Just throw this in your startup code (and it shouldn't hurt non-skunkboard carts, AFAIK):

 

	move.l	#$C00000, a5		; a5 = HPI write address, read data
	move.w	#$4003, (a5)		; set 6MB mode
	move.w	#$4BA0, (a5)		; Select bank 0

You can turn off 6MB mode with the standard reset: move.w #$4001, (a5) ; set flash read-only mode

[VladR]

Hi Tursi,

 

Great to see you here ! Apologies for naive question, but how exactly does 6 MB work with skunk ? Is it via bankswitching (as in older consoles), or can you actually directly run code from above 2MB area (e.g. what happens when instruction pointer crosses $200000 - red screen perhaps) ? It's entirely possible this is described in skunk manual, but I don't have access to that in next few days and wanna use the opportunity.

 

I am routinely hitting the 2 MB limit with my jag experiments, and it would benefit the end result greatly, if I could use higher-resolution textures and had more space for computations and could use bigger look-up tables (there's never enough memory for those )

[+CyranoJ]

Hi Tursi,

 

Great to see you here ! Apologies for naive question, but how exactly does 6 MB work with skunk ? Is it via bankswitching (as in older consoles), or can you actually directly run code from above 2MB area (e.g. what happens when instruction pointer crosses $200000 - red screen perhaps) ? It's entirely possible this is described in skunk manual, but I don't have access to that in next few days and wanna use the opportunity.

 

I am routinely hitting the 2 MB limit with my jag experiments, and it would benefit the end result greatly, if I could use higher-resolution textures and had more space for computations and could use bigger look-up tables (there's never enough memory for those )

 

No, you still only have 2mb of RAM

 

You can store data in the linear address range above $800000 for 6mb.

[VladR]

6MB is nice but still limited I think.

I understand your point (e.g. Atari 800 with 32 MB), but 6 MB is actually quite a lot ! It's not just 3x more. It's way more than that. Once you factor in 2 screen buffers for double buffering, start-up/loading/menu bitmaps, audio data, various look-up tables, actual code (duh), you are down to maybe 0.6 MB free RAM for textures/meshes/everything else. Not exactly much.

 

If, suddenly, you have 4 MB more, that's like, Holy crap! I, for one, am very excited

 

We could finally have double-buffered 2D game in 1400x240xCRY (a screen buffer takes ~1.3 MB, so you obviously cannot have two now and updating single buffer at run-time - well good luck with that )

[+CyranoJ]

I understand your point (e.g. Atari 800 with 32 MB), but 6 MB is actually quite a lot ! It's not just 3x more. It's way more than that. Once you factor in 2 screen buffers for double buffering, start-up/loading/menu bitmaps, audio data, various look-up tables, actual code (duh), you are down to maybe 0.6 MB free RAM for textures/meshes/everything else. Not exactly much.

 

If, suddenly, you have 4 MB more, that's like, Holy crap! I, for one, am very excited

 

We could finally have double-buffered 2D game in 1400x240xCRY (a screen buffer takes ~1.3 MB, so you obviously cannot have two now and updating single buffer at run-time - well good luck with that )

 

Except you have completely misunderstood it again. It's ROM.

[doctorclu]

Before this thread get locked, thanks for everything Tursi!

[Songbird]

OK, I can confirm the issue is not in my code. If I take the same 1MB slideshow binary and put it within the first 4MB, every photo displays correctly. If I move that slide show so it's in the 5-6MB range, every photo displays correctly. It's only if I put this slide show so it straddles the 4MB boundary that it experiences corruption.

 

The CGE 5th slide show was written back in 2002, and I know it works on a real Jaguar CD unit. I'm not changing the slide show code at all in these experiments; I'm just changing the pointer to where the list of slides is located in cart ROM.

 

So, I'm guessing I'm still seeing this corruption at the 4MB boundary like you described, and this is after I upgraded my Skunk with the latest BIOS from this thread.

[+CyranoJ]

So, I'm guessing I'm still seeing this corruption at the 4MB boundary like you described, and this is after I upgraded my Skunk with the latest BIOS from this thread.

 

Can you dump the 8k at the boundary using the skunk console? You'll probably see the BIOS in the file.

[Tursi]

Thanks for fielding questions for me above there.

 

Regarding the 6MB fix, I'll take a closer look at it, but I won't be able to for a couple of weeks - out of town this weekend, but next weekend should be free. Possible (probable even) that I screwed it up, but I'd like to hear if you still see the corruption even when flashing and running a 6MB file as a single step (as that's the test case I used) - so "jcp -6f file.cof"

 

I did review the code and the only time it looks like it's writing the BIOS to bank 2 is when you start bank 2, but it could be something equally dumb like that 8k block is still being skipped by JCP when it writes.

[Songbird]

Yes, I can confirm I was using "jcp -6f cge5th.rom" to flash it and it still had the corruption. Also if I reset the Jag and do "jcp -6b $802000" I get the same results.

 

It's not really holding me up for what I'm doing; I just wanted to be sure my process for extracting CD tracks and writing them to the Skunkboard is working properly. And since I can access 6MB of ROM space, I could just avoid straddling the boundary for now as a work-around.

[Songbird]

 

Can you dump the 8k at the boundary using the skunk console? You'll probably see the BIOS in the file.

I actually haven't incorporated the Skunk console into a program yet -- I have mostly been changing screen color as a simple way to debug so far. But I need to do this, so I can capture better debug output going forward. Then I could also confirm what I see at the boundary.

[+CyranoJ]

I actually haven't incorporated the Skunk console into a program yet -- I have mostly been changing screen color as a simple way to debug so far. But I need to do this, so I can capture better debug output going forward. Then I could also confirm what I see at the boundary.

 

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

 

Then browse to the RAM

[+orpheuswaking]

Stupid question, I got my original skunkboard a long time ago, How to I verify if it is Rev1 or Rev 2? (Also is there anyway to do this without opening the case I put it in... I'll destroy the sticker doing so )

[Songbird]

Doesn't "jcp -*" tell you that?