Jump to content
SainT

Upcoming Jaguar SD Cartridge

Recommended Posts

Anything FAT32 formatted -- so up to 32gb. That should cover all ROM's and CD's.

  • Like 11

Share this post


Link to post
Share on other sites

Anything FAT32 formatted -- so up to 32gb. That should cover all ROM's and CD's.

I've formatted things up to 1TB as FAT32 - there was a point where that's all a Wii would read, which worked fine. I did have to use software other than Windows to do it, since Windows doesn't give the option at that size. So would a FAT32 formatted 64GB work or is there still a size limit even if it is FAT32? I'm sure there's stuff I don't understand here. Not that it's needed just curious.

Share this post


Link to post
Share on other sites

I've formatted things up to 1TB as FAT32 - there was a point where that's all a Wii would read, which worked fine. I did have to use software other than Windows to do it, since Windows doesn't give the option at that size. So would a FAT32 formatted 64GB work or is there still a size limit even if it is FAT32? I'm sure there's stuff I don't understand here. Not that it's needed just curious.

 

Same here. FAT32 has plenty of space: It is 2^32-4 clusters! So 2GB with 512 byte cluster. But since the games are multiple of 2MB, one can increase the cluster.

But then, the FATFS (let me guess: ChanFS) or better the µC must be able to handle it.

Share this post


Link to post
Share on other sites

Right.

From the docs:

The graphics subsystem transfers data to or from external memory by becoming the master of the co-

processor bus. This bus has a 64-bit (phrase) data path, and a 24-bit address, with byte resolution. This bus has

multiple masters, and ownership of it is gained by a bus request/acknowledge system, which is prioritised, i.e.

ownership can be lost during a request (but not during a memory cycle). The graphics subsystem actually

contains two bus masters, the Graphics Processor and the Blitter.

The graphics subsystem also acts as a slave on the IO bus. This bus normally has a 16-bit data path, and allows

external processors to access memory and registers within the graphics subsystem. As the data path within the

graphics subsystem is 32-bit, all reads and writes must be in pairs.

 

I just found the page, and looking at the diagram I still think the GPU only has 32bit external access. The diagram beneath that text doesn't label things clearly. At the bottom is the 64bit system bus, below the GPU bus gateway. The blitter connects directly to the 64bit side of the gateway. Above the gateway is the 32bit local GPU bus, which connects to the GPU core and GPU local RAM (as well as blitter, I imagine for speed and convenience).

 

I believe that to say make a phrase read/write the GPU would fetch or write twice to the main RAM, I doubt the gateway does a 64bit r/w operation, I don't think it forms part of the RISC core.

 

SCPCD probably knows 100% given his tinkering :)

  • Like 3

Share this post


Link to post
Share on other sites

I believe that to say make a phrase read/write the GPU would fetch or write twice to the main RAM, I doubt the gateway does a 64bit r/w operation, I don't think it forms part of the RISC core.

 

 

I think you are right. The info is split into little piece throughout the doc:

v8, page 36:

The only difference to the programmer is that only 32-bit transfers are possible within the

GPU local address space, whereas 8, 16, 32 or 64-bit transfers are permitted externally.

 

This even means: No way to phrase load from CD-ROM address range and phrase store to internal RAM. Reading the high-long from the HW register and then storing it separately is complete waste of time.

  • Like 2

Share this post


Link to post
Share on other sites

GPU as a 32-bit bus and so, GPU internal access is 32-bit.

 

But, it can do 64-bit external access because the Hi-data register is part of the 64-bit Gateway interconnection.

 

To speed up DRAM memory read/write, i will probably advise to use loadp/storep, but for ROM1 address space, i think it's more easiest to use standard load/store for optimisation.

with loadp you have to be sure that hidata is properly loaded before doing the storep or hidata read, this implies :

- to wait that the destination register is written back using the scoreboard detection

Or

- to insert enough usefull instruction before the storep instruction or hidata read (see my ST2Jag optimised code from Orion_'s original code)

 

 

When it's DRAM memory, you know that the memory controller will take the same number of bus cycle to read the data than standard load/store so it's easy to insert some instructions (supposing the bus is not taken by a highest priority) .

But with ROM1, you don't (generally) know the width of the card and the selected speed, in any case, it will take at least 2x5 cycles to read 64-bit data for highest ROM1 speed with 32-bit size.

 

If you use GPU interrupts :

- don't use external load when using loadp

- if you access ROM1 with loadp and can't do enough instruction, GPU will be in scoreboard wait state as you will probably need the loadp result, and so delay the interrupt

in other word, you will kill GPU performance as it will be very difficult to keep the instruction flow.

Using standard load will reduce the overrall pending time.

 

 

Anyway, the speedest way to copy data will be the Blitter in phrase mode (if there is enough data to copy comparing to the time to set blitter registers), but it also implies that the blitter need to be available to do that.

Edited by SCPCD
  • Like 6

Share this post


Link to post
Share on other sites

I'm getting more and more excited, just by seeing all the support to SainT from you Jaguar development Gods.

 

I think I speak for most of the community eagerly awaiting the JagSD's release: THANK YOU FOR YOUR INPUT!!

 

leonardo-dicaprio-cheers-awesome-meme.jp

  • Like 5

Share this post


Link to post
Share on other sites

In-case you don't follow Twitter... I've just got the first part of a video streaming from a CD image booting Baldies. Finally feels like things are becoming a bit more stable!

post-37728-0-44599300-1548867169_thumb.jpg

post-37728-0-22793800-1548867177_thumb.jpg

  • Like 29

Share this post


Link to post
Share on other sites

Is this a BIOS replacement or monitoring the address lines?

I've recompiled the VLM boot ROM present on the JagCD with modifications to run on the JagSD and also written a new bios. It's pretty bare bones, but it would seem enough to run FMV and a game. I'll need to run through all the CD images I can find and see what needs tweaking. But the important thing is the bios is fully under my control, so it can be tweaked without trouble, so it should be possible to get all CD games working now.

  • Like 18

Share this post


Link to post
Share on other sites

I've recompiled the VLM boot ROM present on the JagCD with modifications to run on the JagSD and also written a new bios.

(assuming your married...)

Spouse 1

"So what did you do today honey?"

 

Spouse 2

"Oh... Nothing big, just wrote a new working BIOS for the Jaguar CD."

 

Spouse 3

"Really? Is that all?"

 

To us commoners, this seems pretty amazing. I am super excited for this by the way. Thanks to everyone here that has worked with SainT to get through this road block, and of course thanks to SainT for moving mountains.

  • Like 5

Share this post


Link to post
Share on other sites

I've recompiled the VLM boot ROM present on the JagCD with modifications to run on the JagSD and also written a new bios. It's pretty bare bones, but it would seem enough to run FMV and a game. I'll need to run through all the CD images I can find and see what needs tweaking. But the important thing is the bios is fully under my control, so it can be tweaked without trouble, so it should be possible to get all CD games working now.

Ok, so all ULS CD images should fail as they reload (And patch to fix cd_swap) the bios.

 

However, this isn't a problem because it loads a track to RAM so just put that on the SD card as a .bin file!

  • Like 1

Share this post


Link to post
Share on other sites

(assuming your married...)

Spouse 1

"So what did you do today honey?"

 

Spouse 2

"Oh... Nothing big, just wrote a new working BIOS for the Jaguar CD."

 

Spouse 3

"Really? Is that all?"

...Spouse 3? Feeling a bit polygamous, are we? :D Reminds me of 7:24 from a Ren & Stimpy cartoon...

 

More seriously: this is great news!

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

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...