Jaguar CD Unleashed: the CD BIOS emulation project

[+CyranoJ]

I've never used ULS, but I presume the Reboot splash screen is a data track in session 0? If so, that could be another good test for JagCDU emulation -- a single-load game such as Native built into a CD via ULS would then have two data tracks.

 

Since ULS is obsoleted, does JiFFI do all of the same things for producing a CD game?

 

The JiFFI CD create function is a wrapper around ULS

 

Nope, the splash is in session 1, as is the encryption.... the embedded binary is tucked away safely in session 0, where it won't affect the checksum data. Protection = bypassed All disks have the same key.

Edited July 28, 2016 by CyranoJ

[Songbird]

Nice solution! I will have to try that sometime with JagCDU.

[Songbird]

@Songbird,

 

Thanks for all your work - it's hero's like you that keep the retro scene so fascinating and alive.

 

Would you perhaps have video of a CD image booting from the Skunkboard yet? This isn't to nag you, I'm really just excited to see the progress of the development.

 

Thanks,

Mark.

Perhaps. It's not much more exciting than what I've already said, which means I can play Protector RESURGENCE, Frog Feast, and the CGE 5th slideshow all without a CD player now. You won't see any of the traditional CD boot screens (VLM, etc.) since this is a cartridge booting a CD image, so it pretty much just starts the game right away.

Edited July 29, 2016 by Songbird

[+rdemming]

 

The JiFFI CD create function is a wrapper around ULS

 

Nope, the splash is in session 1, as is the encryption.... the embedded binary is tucked away safely in session 0, where it won't affect the checksum data. Protection = bypassed All disks have the same key.

 

Instead of storing the data in session 0 I know another solution which I wanted to call a DIET disk.......

 

 

 

 

 

There is another place on the CD where you can store data that is not checked by the decryption process. A long time ago I was thinking what tracks were and were not processed by the encryption process. Of course session 0 (audio session) in not taken into account but the other place on the disk that cannot be taken into account by the encryption process is...... the encryption track itself

 

Thus DIET = Data in Encryption Track

 

I've tested it a long ago, I took an existing encrypted CD and added extra data after the encryption data in the encryption track, burned it to CD and it still worked. But I never got the time to make a CD that really reads the extra data from the encryption track.

 

The idea was to have a generic boot track that reads and executes the data stored after the encryption data in the encryption track. Then encrypt the disk. After the encryption the data of the program to boot is added to the encryption track. And same as putting data in session 0, all disks would have the same key.

 

One big advantage of storing the data in the encryption track compared to placing the data in session 0 is that the extra data can be of arbitrary length. When storing the data in session 0, the length of session 0 must always be the same because the decryption process takes into account the start position of the data session. That is why an ULS disk image has always the same (large) size even when the program is small. Thus a DIET disk would be "slimmer" than an ULS disk.

 

Since the data can be of arbitrary length this opens the possibility to have an utility that creates one disk with multiple programs selected by a generic menu. The program selector/loader would be in the boot track. The encryption track would then contain some kind of directory followed by the data of all the applications.

 

Unfortunately I never got the time to implement this but if I triggered your curiosity about the "data in encryption track" concept, you are welcome to implement it

 

 

 

 

Robert

[+CyranoJ]

 

Instead of storing the data in session 0 I know another solution which I wanted to call a DIET disk.......

 

 

 

 

 

There is another place on the CD where you can store data that is not checked by the decryption process. A long time ago I was thinking what tracks were and were not processed by the encryption process. Of course session 0 (audio session) in not taken into account but the other place on the disk that cannot be taken into account by the encryption process is...... the encryption track itself

 

Thus DIET = Data in Encryption Track

 

I've tested it a long ago, I took an existing encrypted CD and added extra data after the encryption data in the encryption track, burned it to CD and it still worked. But I never got the time to make a CD that really reads the extra data from the encryption track.

 

The idea was to have a generic boot track that reads and executes the data stored after the encryption data in the encryption track. Then encrypt the disk. After the encryption the data of the program to boot is added to the encryption track. And same as putting data in session 0, all disks would have the same key.

 

One big advantage of storing the data in the encryption track compared to placing the data in session 0 is that the extra data can be of arbitrary length. When storing the data in session 0, the length of session 0 must always be the same because the decryption process takes into account the start position of the data session. That is why an ULS disk image has always the same (large) size even when the program is small. Thus a DIET disk would be "slimmer" than an ULS disk.

 

Since the data can be of arbitrary length this opens the possibility to have an utility that creates one disk with multiple programs selected by a generic menu. The program selector/loader would be in the boot track. The encryption track would then contain some kind of directory followed by the data of all the applications.

 

Unfortunately I never got the time to implement this but if I triggered your curiosity about the "data in encryption track" concept, you are welcome to implement it

 

 

 

 

Robert

 

I started working on ULS 20 which had a 650MB data track in session 0 that had a file system inside it for this very reason, and then the bootloader (in session 1) would always run 'AUTOBOOT.ABS' from the hidden filesystem.

 

Long story short, I couldn't be bothered to finish it - But I do have an encrypted, bootable CD master with a 650 storage capacity.

[mqark]

Perhaps. It's not much more exciting than what I've already said, which means I can play Protector RESURGENCE, Frog Feast, and the CGE 5th slideshow all without a CD player now. You won't see any of the traditional CD boot screens (VLM, etc.) since this is a cartridge booting a CD image, so it pretty much just starts the game right away.

You'd be surprised how easily I get excited

 

But fair enough... Congratulations are well deserved.

[+rdemming]

 

I started working on ULS 20 which had a 650MB data track in session 0 that had a file system inside it for this very reason, and then the bootloader (in session 1) would always run 'AUTOBOOT.ABS' from the hidden filesystem.

 

Long story short, I couldn't be bothered to finish it - But I do have an encrypted, bootable CD master with a 650 storage capacity.

 

I'm not surprised

Loading the menu via an "AUTOBOOT.ABS" from the "file system" instead of the boot-track is indeed the way to go, that's much more flexible than having the menu in the boottrack

If you ever decide to go back to the project, consider storing the data in the encryption track instead of session 0 so the CD image would have flexible size and not always be 650MB large even when stored data is smaller.

[+CyranoJ]

 

I'm not surprised

Loading the menu via an "AUTOBOOT.ABS" from the "file system" instead of the boot-track is indeed the way to go, that's much more flexible than having the menu in the boottrack

If you ever decide to go back to the project, consider storing the data in the encryption track instead of session 0 so the CD image would have flexible size and not always be 650MB large even when stored data is smaller.

 

It wouldn't really matter tho because:

 

1. It'd never be uploaded as a raw image, and all those zeros will pack down to... zero!

2. Like I said, I couldn't be bothered finishing it!

 

Especially as Orion_ released a file system (although he didn't make it universal booting)

 

oh, and

 

3. Always re-load and re-init the CD BIOS, just to foil Carl (j/k)

Edited July 29, 2016 by CyranoJ

[Songbird]

You'd be surprised how easily I get excited

 

But fair enough... Congratulations are well deserved.

OK, here you go... it's not too fancy, but hopefully gives a little more insight and an actual demo of JagCDU in action.

 

Edited August 9, 2016 by Songbird

[TheDevil'sCompass]

This is very cool, Carl. Amazing work!

[+Saturn]

Incredible project! That one and only like on the video at YT is mine, btw

[Zerosquare]

Carl, have you thought about streaming the data from a PC using the Skunkboard's USB connection? That would be a nice addition for those who already bought the Skunkboard.

[Songbird]

Actually, my next step is to see if I can get the provided sample USB driver working on the Skunk for a simple I/O direct from a USB flash device. Then, I would merge that code with my existing JagCDU code (which only supports single transfers from CD, no streaming) so games would run off USB memory instead of the 6MB cartridge ROM space. After that, I would look at the streaming support.

 

I could look into streaming from the PC, but that would require a) a constant PC connection for users and b) more work on my part. My preference is to have a stand-alone device, such as a USB stick or SD card, which plugs into a custom cart, such as a Skunk or SainT's proposed Jag SD cart. That would be convenient and relatively predictable from a user experience perspective.

 

[dilinger]

Hi Carl,

At first, congrats for your work and dedication to our community. I have a comment/question about your next step. I believed the USB port found on the Skunkboard was not physically connected. I found this info on a web site:

"What are the two large USB ports for?

-When originally designed, Skunkboard was intended to support USB memory sticks for booting and loading software. This functionality is not yet developed.
-There are no plans to develop these USB ports at this time."

So does it means it was a matter of software and not a hardware issue?

[Songbird]

I assume the USB ports are physically connected. Tursi pointed me to some USB driver code included with the Skunk full distribution which is intended to interface with the USB ports as a mass storage device.

 

However, I have never dealt with USB interfacing before, so this will be a learning curve for me. If someone else wanted to figure out how to read from USB and dump in Jaguar RAM, I would be happy to incorporate said code into JagCDU.

[Zerosquare]

Unless the support code you have is (really) good, I can tell you from experience that USB is a pain to understand and get working.

 

If I were you, I'd start with streaming data from a PC, since there are already working communication functions (if I understood correctly - I don't have a Skunkboard), and support USB devices later. It will make it easier to debug, especially since you can easily monitor what's happening in real time from the PC side.

 

That's just my opinion though

[dilinger]

I assume the USB ports are physically connected. Tursi pointed me to some USB driver code included with the Skunk full distribution which is intended to interface with the USB ports as a mass storage device.

I remember to have read a couple of text files mentioning WiP on these 2 USB ports. Could you point me to this USB driver code? I have the Skunk full distribution zip file (the one available in the Tursi's web site), so I will be able to find the code if you can give me the filename(s). I do not promise anything but I can have a look at this stuff.

Zerosquare is correct, the Skunklib is the communication functions library.

[Songbird]

Unless the support code you have is (really) good, I can tell you from experience that USB is a pain to understand and get working.

 

If I were you, I'd start with streaming data from a PC, since there are already working communication functions (if I understood correctly - I don't have a Skunkboard), and support USB devices later. It will make it easier to debug, especially since you can easily monitor what's happening in real time from the PC side.

 

That's just my opinion though

You may have a point. I am definitely looking for a simple intermediate step here, where I can do transfers from a storage medium bigger than the 6MB ROM to Jaguar RAM. That still won't help get most full Jaguar CD games running, but it's a step in the right direction.

 

To dilinger: the file in the Skunk distribution is called usb.c.

[Timmay]

You may have a point. I am definitely looking for a simple intermediate step here, where I can do transfers from a storage medium bigger than the 6MB ROM to Jaguar RAM. That still won't help get most full Jaguar CD games running, but it's a step in the right direction.

 

To dilinger: the file in the Skunk distribution is called usb.c.

 

From what I understand the USB ports are connected, but require a firmware update to support them. I believe i2S support is implemented too, so with some careful programming, it would be possible to emulate the CD drive, and a mass storage device on the Skunkboard. This could be a much quicker and simpler solution than waiting for the Jaguar SD card.

[dilinger]

To dilinger: the file in the Skunk distribution is called usb.c.

It makes sense. :-)

There are also information & useful notes in the z_misc directory; and the "theory of operation" text file gives some ideas/clues of what Tursi had in mind.

I will dig a little but not sure if my USB experiences will be enough.

[Stephen Moss]

Actually, my next step is to see if I can get the provided sample USB driver working on the Skunk for a simple I/O direct from a USB flash device.

 

I could look into streaming from the PC, but that would require a) a constant PC connection for users and b) more work on my part.

 

 

I wish you luck although I am not sure both are possible, as you would have to use the SkunkBoard as a bus Master for the Memory stick and probably as slave for the PC because as far as I know all PC USB ports are all Masters and while I have not tried I doubt they can be easily switch to slaves if at all. Even if the SkunkBoard has a USB OTG device fitted so you can switch between the two catering for both will make things more difficult.

 

As Zerosquare said USB is (in my opinion) an unnecessarily complicated pain in the but, however from my limited understanding of it you may be able to take some short cuts as you are only expecting the one type of device (Memory stick) you can tailor you USB code to that and if they only have one configuration you should not need to tell it which configuration you want it to be and you may even be able to skip most of the enumeration process and just use the Control pipe although using the Control Pipe alone may not be possible for bulk transfers.

 

However, I am far from an expert on USB. I have not had time to touch my USB project for a year and only got as far as getting slave device connect/disconnect and addressing working as I kept running into Stall interrupts probably due to time delays caused by the PIC sending progress data to the LCD resulting in the Mouse going into suspend or disconnecting from the bus. Thus you may find you need access to a USB bus analyser for debugging as other types of output such as the very slow SkunkConsole or even writing to the Jaguar Screen may be too slow as you have to keep polling the slave device at a certain rate to keep it interested.

[jericho_21]

This sounds like an awesome project. I like the idea of it, but I was curious. I understand that it is an emulation project. Can you keep the original CD-BIOS? My understanding, from these posts, is that the Skunkboard loads your custom BIOS and just circumvents the original. Am I correct on this? I do not want to hack into my CD-ROM or my Jaguar to do this. Also, is it just through the Skunkboard? Most Jag users do not have one, including myself. I cannot build one because, well, it costs to build one. I understand it will take some time to develop. Which is my next question: Is there a time frame for more development on this project? Thanks.

[SainT]

On 10/18/2017 at 11:07 AM, jericho_21 said:

This sounds like an awesome project. I like the idea of it, but I was curious. I understand that it is an emulation project. Can you keep the original CD-BIOS? My understanding, from these posts, is that the Skunkboard loads your custom BIOS and just circumvents the original. Am I correct on this? I do not want to hack into my CD-ROM or my Jaguar to do this. Also, is it just through the Skunkboard? Most Jag users do not have one, including myself. I cannot build one because, well, it costs to build one. I understand it will take some time to develop. Which is my next question: Is there a time frame for more development on this project? Thanks.

 

I'm working on the CD support for the Jag cart. This will include the entire CD boot ROM with VLM, etc... with the BIOS part modified to read ISO's from the memory card. As you can boot a cart plugged into the JagCD, you should just be able to boot the Jag cart CD support ROM and run CD games from memory card while the CD drive is attached. I should have the CD support working on the Jag cart in a few weeks, I'm just waiting on new PCB's at the moment.

 

I don't mean to derail this thread, just to make people aware "full" CD support will be available soon.

Edited October 25, 2019 by SainT

[PeterG]

 

I'm working on the CD support for the JagSD. This will include the entire CD boot ROM with VLM, etc... with the BIOS part modified to read ISO's from the SD card. As you can boot a cart plugged into the JagCD, you should just be able to boot the JagSD CD support ROM and run CD games from SD while the CD drive is attached. I should have the CD support working on the JagSD in a few weeks, I'm just waiting on new PCB's at the moment.

 

I don't mean to derail this thread, just to make people aware "full" CD support will be available soon via the JagSD.

 

As you have mentioned the VLM, does this mean that we will be able to feed the SD Cart with music and have the VLM react to it? This might be wishful thinking but ever since Glenn Bruner developed his (unfortunatley unreleased) VLM cart that would allow an external source to feed music into the VLM I have been dreaming about this feature. Although I wonder in what format the music would have to be on the JaguarSD.

Not that you don`t have a long list of features for your JagSD cart but this one is really something I`d like to see. :-)

[SainT]

 

As you have mentioned the VLM, does this mean that we will be able to feed the SD Cart with music and have the VLM react to it? This might be wishful thinking but ever since Glenn Bruner developed his (unfortunatley unreleased) VLM cart that would allow an external source to feed music into the VLM I have been dreaming about this feature. Although I wonder in what format the music would have to be on the JaguarSD.

Not that you don`t have a long list of features for your JagSD cart but this one is really something I`d like to see. :-)

 

Yes. You'd just need an ISO of an audio cd.