VladR Posted January 22, 2017 Share Posted January 22, 2017 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 ! Quote Link to comment Share on other sites More sharing options...
SainT Posted January 22, 2017 Author Share Posted January 22, 2017 (edited) 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 October 25, 2019 by SainT 1 Quote Link to comment Share on other sites More sharing options...
VladR Posted January 22, 2017 Share Posted January 22, 2017 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 Quote Link to comment Share on other sites More sharing options...
Guitari Posted January 22, 2017 Share Posted January 22, 2017 If other people can see them, they are real. Otherwise, it's just in your head. Unless the other people who can see them are not real. Quote Link to comment Share on other sites More sharing options...
SainT Posted January 22, 2017 Author Share Posted January 22, 2017 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. 1 Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted January 22, 2017 Share Posted January 22, 2017 The Jag code will be open source, the hardware will not -- the line is very clear. Awesome, I'll be able to abstract it into RAPTOR 2 Quote Link to comment Share on other sites More sharing options...
JagChris Posted January 22, 2017 Share Posted January 22, 2017 (edited) 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 January 22, 2017 by JagChris Quote Link to comment Share on other sites More sharing options...
SainT Posted January 22, 2017 Author Share Posted January 22, 2017 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... Quote Link to comment Share on other sites More sharing options...
JagChris Posted January 22, 2017 Share Posted January 22, 2017 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. Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted January 22, 2017 Share Posted January 22, 2017 Does anybody use elf? I have never seen a single binary in that format. .abs/.cof are the primary formats for binary uploads. Seems like a lot of work to go to for no gain. 1 Quote Link to comment Share on other sites More sharing options...
JagChris Posted January 22, 2017 Share Posted January 22, 2017 (edited) 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 January 22, 2017 by JagChris Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted January 22, 2017 Share Posted January 22, 2017 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? 2 Quote Link to comment Share on other sites More sharing options...
JagChris Posted January 23, 2017 Share Posted January 23, 2017 (edited) So if it's not going to also be compatible with the skunkboard, then what? You want to limit future devs who get an SD to either owning an old PC with a developer jag, or emulation? Edited January 23, 2017 by JagChris Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted January 23, 2017 Share Posted January 23, 2017 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. 2 Quote Link to comment Share on other sites More sharing options...
JagChris Posted January 23, 2017 Share Posted January 23, 2017 (edited) 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 January 23, 2017 by JagChris Quote Link to comment Share on other sites More sharing options...
+CyranoJ Posted January 23, 2017 Share Posted January 23, 2017 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. 1 Quote Link to comment Share on other sites More sharing options...
JagChris Posted January 23, 2017 Share Posted January 23, 2017 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. Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted January 23, 2017 Share Posted January 23, 2017 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. Quote Link to comment Share on other sites More sharing options...
JagChris Posted January 23, 2017 Share Posted January 23, 2017 I think this is the most important point. If the creator expresses no interest in supporting format X That's why i am asking. To see if he would be interested. He might say yes. ? 2 Quote Link to comment Share on other sites More sharing options...
VladR Posted January 23, 2017 Share Posted January 23, 2017 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... Quote Link to comment Share on other sites More sharing options...
JagChris Posted January 23, 2017 Share Posted January 23, 2017 (edited) 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 January 23, 2017 by JagChris Quote Link to comment Share on other sites More sharing options...
SainT Posted January 23, 2017 Author Share Posted January 23, 2017 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. 5 Quote Link to comment Share on other sites More sharing options...
JagChris Posted January 24, 2017 Share Posted January 24, 2017 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. Quote Link to comment Share on other sites More sharing options...
SainT Posted January 24, 2017 Author Share Posted January 24, 2017 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. 1 Quote Link to comment Share on other sites More sharing options...
JagChris Posted January 24, 2017 Share Posted January 24, 2017 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.