Jump to content
IGNORED

Upcoming Jaguar Game Drive Cartridge


SainT

Recommended Posts

Any features like the MP3 decoding would likely come after initial release, yes -- not essential but nice to have.

Thanks for confirming that :)

 

 

And as the microcontroller and CPLD will be updatable via software, anything can be done via updates.

So, the firmware will be open-source ? Hosted on something like GitHub ? In that case, as a developer, I could literally implement any functionality, or adjust existing functionality.

 

 

SD cards are accessed in sectors -- larger ones anyway, the original spec used byte addressing as I remember, and hence was limited to 4GB. So that gives something like 2TB. I cant remember if block size varies at all from 512 bytes, but either way 2tb isnt going to be limitation.

That's great to hear that 4 GB won't be the limit. I know it sounds alike a lot to many people, but my terrain dataset (from my prior coding on PC) with lightmaps, textures, and heightmap data is 20+GB, which is why I wasn't even considering CD with its meager 0.7 GB.

 

 

Actual hardware is a little way off yet, I'll consider what's happening when I have some units to give out. My priority will be making sure of compatibility with all commercial titles initially, but I welcome discussion of any features people may want so I can make sure the hardware is built with as much flexibility as possible. There is a fair bit of logic space on the CPLD at the moment, so additional functionality is possible...

Awesome! Keep the great work !

Link to comment
Share on other sites

On 1/22/2017 at 3:38 PM, VladR said:

So, the firmware will be open-source ? Hosted on something like GitHub ? In that case, as a developer, I could literally implement any functionality, or adjust existing functionality.

 

 

Only the Jaguar side code will be open source -- the CPLD and Microcontroller portions will be closed. So the same as the Lynx cart. I may open this eventually, but its not something I'm considering in the short term.

 

I will be active in providing updates, however, so if a feature is valuable enough to add, I will do my best to do so.

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

Only the Jaguar side code will be open source -- the CPLD and Microcontroller portions will be closed.

So, what kind of functionality exactly will be open source then ? Since we don't see your architectural breakdown of the components, it's impossible to guess for me where exactly you draw the line, as you might choose to expose either just the headers or their implementation, or anything in between both scenarios.

 

It's, obviously, only your call, so we're good either way :)

Link to comment
Share on other sites

So, what kind of functionality exactly will be open source then ? Since we don't see your architectural breakdown of the components, it's impossible to guess for me where exactly you draw the line, as you might choose to expose either just the headers or their implementation, or anything in between both scenarios.

 

It's, obviously, only your call, so we're good either way :)

 

The Jag code will be open source, the hardware will not -- the line is very clear.

 

There will be documentation on the hardware, ie. memory map for registers and what everything does. How it does what it does you don't need to worry yourself about -- much like using the Jag CD unit for example.

  • Like 1
Link to comment
Share on other sites

In what way "emulate"? I intend to have debugging capabilities (with a header which can be connected to the Jag PCB via a ribbon cable, like the Alpine), but I'm not sure what capabilities of the skunkboard would be wanted? Please let me know what you mean in more detail so I can consider what I can do.

Here is the skunkboard webpage with full documentation, PCB etc.

 

http://harmlesslion.com/cgi-bin/showprog.cgi?search=skunkboard

 

The skunkboard also plugs in like a cartridge but needs no external cable or a developer jag for it's fiunctionality.

 

There are three versions, slightly different. The one featured on this video is the very first.

 

https://m.youtube.com/#/watch?v=PTnAUFVrWSs

 

If you're already aware of it that's great. Am not sure all the tools being developed on the skunkboard for development will work on the alpine. Or vice versa

Edited by JagChris
Link to comment
Share on other sites

Yes, I am aware of the skunkboard, what functionality is it you want which it supports? The software between alpine and skunkboard is not compatible, no.

 

Do you have any idea what you actually want from 'emulating' any of this hardware??

 

The extra cable from the jag allows nmi's to be triggered and the state of the cpu to be monitored from the debugging hardware such that you can do hardware breakpoints etc...

Link to comment
Share on other sites

The abi!ity to read the elf file format like the skunkboard software. Perhaps general compatibility with jcp\jdb? Blanking on the name of the files. A few programmers are furthering the SKunkboards debug powers.

 

Trying to avoid future devs who just got an SD card/new on the scene to have to start over or use an old PC setup for debug is all.

Link to comment
Share on other sites

Yeah a couple that I know of.

 

Not a huge batch but the skunkboard/ELF/code::blocks/gui topic has hit a silly amount of views.

 

No gain? Maybe not for you but why limit it for others if it can be added reasonably?

 

In the end it's saints call.

Edited by JagChris
Link to comment
Share on other sites

Yeah a couple that I know of.

 

Not a huge batch but the skunkboard/ELF/code::blocks/gui topic has hit a silly amount of views.

 

No gain? Maybe not for you but why limit it for others if it can be added reasonably?

 

In the end it's saints call.

 

Why add additional delays to this for a handful of people who could probably move to the standard binary format instead of working on a new one?

  • Like 2
Link to comment
Share on other sites

My two cents: the developers buying this new flash cart are ones who don't fully use the Skunkboard. I am OK with just having at minimum one backwards compatible format. As long as I can compile, test on emulator and then upload to cart. Rinse. Repeat.

Our emulation scene is nowhere near mature. Especially debug. That would be severely limiting.

 

COFF was abandoned in favor of ELF because ELF supported some of the newer compiler functions better. Why would we not want the option to have this?

 

How much of a delay could it be to implememt this? Didn't take Frank Wille long to create and implement the jag ELF format into his linker and assembler for those who wanted it amidst all the other stuff he was doing. Or Tursi to support the format in the skunk board software. I can't imagine the delay being huge.

 

But in the end like I said it's sainTs ball game.

Edited by JagChris
Link to comment
Share on other sites

COF abandoned for ELF?

 

Show me the last Jaguar homebrew game released in .ELF format, or had .ELF format used *anywhere* in it's development?

 

If it is the primary file format for homebrew claiming it is abandoned is insane.

I am sorry you misread that and perhaps I wasn't clear enough. COFF was abandoned for ELF out there in the wider world for these reasons.

 

Sorry about the misunderstanding.

Link to comment
Share on other sites

Our emulation scene is nowhere near mature. Especially debug. That would be severely limiting.

 

COFF was abandoned in favor of ELF because ELF supported some of the newer compiler functions better. Why would we not want the option to have this?

 

How much of a delay could it be to implememt this? Didn't take Frank Wille long to create and implement the jag ELF format into his linker and assembler for those who wanted it amidst all the other stuff he was doing. Or Tursi to support the format in the skunk board software. I can't imagine the delay being huge.

 

But in the end like I said it's sainTs ball game.

 

I think this is the most important point. If the creator expresses no interest in supporting format X then either you find an end-user workaround or use your developer skills to create a conversion utility. Is either possible for you JagChris?

 

To be clear I'm not arguing this side or that. I'm actually interested in what's possible.

Link to comment
Share on other sites

Well, if it takes him a week, and he's willing to do it, then sure - why not ?

 

But what if it takes more or he does not really want ?

 

Personally, I can live without gdb debugging. It forces you to code using unit-testing methodology, so each time you make some change to the code, you just uncomment the unit test method (beats gdb debugging, btw).

 

3 weeks ago I would promise kingdom and a princess for GPU debugging. Today, meh...

 

But I understand it'll suck for those who don't use COFF...

Link to comment
Share on other sites

Well, if it takes him a week, and he's willing to do it, then sure - why not ?

 

But what if it takes more or he does not really want?

 

 

But I understand it'll suck for those who don't use COFF...

That's why am asking. Can't hurt. If he says no...ok. An extra week? What's an extra week or even a month or two to have the widest available options for those who have been here years? And for those who may come in the future? The final design of the SD card will be permanent.

 

The format is relatively new on the jag and seems to be in use for large projects beyond just proof of concept where this type of debug is useful to them.

 

And we don't even have COFF despite what the filenames say. It's actually a.out.

Edited by JagChris
Link to comment
Share on other sites

Cool, no that's all good. That sort of support isn't something I'm aiming for at release. The primary goal for release is compatibility with all commercial and homebrew ROM software where possible with CD game compatibility the next priority.

 

Development tools will be more a secondary thing, and I hope a community effort. I will make anything like that open source too, so libraries for communicating with the JagSD from the PC, etc... The USB side of things will be just using the standard winusb driver to communicate with the microcontroller on the cart and control things like breakpoints, sending and receiving data, whatever. I already have a framework for this running on my NGPC programmer.

  • Like 5
Link to comment
Share on other sites

Yeah that got a little sidetracked. I am not clear whether this will eventually emulate an Alpine board and be able to run it's tools (wdb etc)or just have the same functionality with tools needing to be written.

 

Not sidetracked in the slightest, as far as I'm concerned -- we got to the bottom of the actual requirements.

 

No, it will not emulate or be compatible with any other existing hardware, but will encompass their functionality where appropriate.

  • Like 1
Link to comment
Share on other sites

 

Not sidetracked in the slightest, as far as I'm concerned -- we got to the bottom of the actual requirements.

 

No, it will not emulate or be compatible with any other existing hardware, but will encompass their functionality where appropriate.

Yeah I meant I got sidetracked in my questions.

 

But thank you for clearing this up. ?

 

If future devs could bypass as much as possible NEEDING(the option to use with it's benefits is cool) some kinda stub developer jag for development on this that would probably be best.

Link to comment
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.
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...