Cumulus Firware Compilation

This is the right place to discuss on how to implement hardware vsync, adding a VIA or AY chipset, puting multiple roms, or how to design a new flash expansion card.
User avatar
Chema
Game master
Posts: 2297
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: Cumulus Firware Compilation

Post by Chema » Sun Jan 26, 2014 5:11 pm

Hi all. I've been playing a bit with my cumulus today. It works perfectly, and I am already loving it.

I will try to instal MPLAB and have a look at the sources. I find the process for loading a disk a bit awkward. Too many button presses and a submenu to reset the Oric. Nothing of importance, but I wonder if it could be made easier. If we could save in the EPROM the name of the last dsk and auto mount it if exsists... Don't know if it could be a good idea.

I am also not sure if it is a good idea to have the disk images as protected by default. Cant we use the file attribute instead? I tried to save my status in space:1999 and failed due to this, I think. Or am I talking nonsense? I must confess it would be more intelligent if I first make some more tests and get used to it, before writing anything here...

Just one more small thing. I had the impression that it took longer to load 1337 and space:1999 than in the videos I watched in youtube. Also the Oric shows the usual initial screen (with the tangerine copyright and the bytes free) for over one second before becoming black and launching Sedoric. But I never saw this on the emulators or videos.

Maybe I am just too excited, and it is my imagination!!

User avatar
Dbug
Site Admin
Posts: 2724
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Cumulus Firware Compilation

Post by Dbug » Sun Jan 26, 2014 6:29 pm

Chema wrote:I will try to instal MPLAB and have a look at the sources. I find the process for loading a disk a bit awkward. Too many button presses and a submenu to reset the Oric. Nothing of importance, but I wonder if it could be made easier. If we could save in the EPROM the name of the last dsk and auto mount it if exsists... Don't know if it could be a good idea.
It's something I changed in my version of the firmware: http://miniserve.defence-force.org/svn/ ... s/fw_dbug/

All you have to do is to press the bottom right button and it will automatically remount the same dsk file and ask you if you want to reset the oric.
Chema wrote:I am also not sure if it is a good idea to have the disk images as protected by default. Cant we use the file attribute instead? I tried to save my status in space:1999 and failed due to this, I think. Or am I talking nonsense? I must confess it would be more intelligent if I first make some more tests and get used to it, before writing anything here...
That makes perfect sense :)
That's also why I decided to make my own little folder: To be able to test without breaking the main code base.

User avatar
coco.oric
Flight Lieutenant
Posts: 454
Joined: Tue Aug 11, 2009 9:50 am
Location: North of France
Contact:

Re: Cumulus Firware Compilation

Post by coco.oric » Sun Jan 26, 2014 6:31 pm

When i'll have this, i'll do some trials like compare it with euphoric or oricutron or with an hxc or a real 3" sedoric drive if i have the time to do it.
coco.oric as DidierV, CEO Member
Image Image

User avatar
ibisum
Wing Commander
Posts: 1024
Joined: Fri Apr 03, 2009 8:56 am

Re: Cumulus Firware Compilation

Post by ibisum » Sun Jan 26, 2014 7:10 pm

That's also why I decided to make my own little folder: To be able to test without breaking the main code base.
We really need to learn how to use the existing source code repository tool to prevent this "DOS-era" practice of copying files around from becoming the norm. I'm deterred by working on the main code, because your version is out there - before I could 'safely' consider moving into this project, I'd have to merge your changes first, and then add some features. It just seems like so much fuss that would be better solved by you using SVN for this purpose, Dbug.

Anyway - I have the following items on my list of things to do with the firmware, so maybe we can coordinate our actions and not write the code 2 or 3 times over?

1. Remember last-loaded .DSK files
2. Config - toggle to boot SEDORIC.DSK automatically, if it exists
3. Config - reboot Oric after .DSK mount (automatically)
4. Figure out some way the Oric can tell the Cumulus to load a .DSK file.
5. Figure out some way the Oric can tell the Cumulus to return a list of .DSK files that are available.

User avatar
Dbug
Site Admin
Posts: 2724
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Cumulus Firware Compilation

Post by Dbug » Sun Jan 26, 2014 8:00 pm

ibisum: My changes are NOT safe, just one example: I removed the 'eject' feature because I did not understand what it did and it looked pointless, but now that I see that people are using the write feature it means that my version of the firmware will just probably leave modified files open and probably corrupt data.

The other thing is that a decent UI should be designed. Not in code, on paper: How do we want the screen and the 5 buttons to be used.

In my version I just removed things gratuitously because I don't need them, and I needed fast access instead.

In the end it may mean that we may want a firmware with multiple modes of operation:
- fast development/iteration mode
- mode to make it easy to navigate fast in a large collection of DSK (possibly with subfolders)
- mode to handle an extended cumulus with selection of stuff from the Oric side
- etc...

I don't want my version to be a branch because that would restrict what I can experiment with. I want to be free to rename files, split files, move things around, delete stuff, rename stuff, change formats and structs and functions and API. Not something that SVN (or GIT or even Perforce) would be happy with, even if we did use branching.

So let me experiment, test my version if you want (all of you), and if there are some features you like I can backport it later. Just stop asking because this really annoys me. And I'm rarely annoyed. (Emphasis added just to get the message through)

Now to be constructive:
The one single most important feature is to implement preferences, with a persistent storage, you can add that if you want, it's a great feature which I tried to add but miserably failed - the c18 did not like the eeprom_read/write calls.

User avatar
Chema
Game master
Posts: 2297
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: Cumulus Firware Compilation

Post by Chema » Sun Jan 26, 2014 9:04 pm

Dbug wrote:I removed the 'eject' feature because I did not understand what it did and it looked pointless, but now that I see that people are using the write feature it means that my version of the firmware will just probably leave modified files open and probably corrupt data.
[\quote]

You've just enlightened me! I am one of those testing the save option, and completely overlooked the eject command.... Probably have a nice corrupt file by now :/
The other thing is that a decent UI should be designed. Not in code, on paper: How do we want the screen and the 5 buttons to be used.
Indeed. That is a nice idea, and it is easy to contribute to it just by dropping ideas on what it may look like.

For instance, and don't jump over me, it is just a first thought, I think I'd prefer the three buttons to work as a sort of up/down/select for all the menus, and the two buttons to change between two screens, such as system and mounted disk images, or even iterate forth/back among different screens.

Godzil
Squad Leader
Posts: 758
Joined: Sat May 21, 2011 7:21 pm
Location: Between UK and France
Contact:

Re: Cumulus Firware Compilation

Post by Godzil » Mon Jan 27, 2014 2:19 am

I dont know how it works for now, but there should be two "soft button" with meaning depending on what displyed on screen (a bit line old phones) at a up/down/select tri button like Chema proposition

(I'm searching for an image..)

User avatar
ibisum
Wing Commander
Posts: 1024
Joined: Fri Apr 03, 2009 8:56 am

Re: Cumulus Firware Compilation

Post by ibisum » Mon Jan 27, 2014 10:42 am

I don't want my version to be a branch because that would restrict what I can experiment with. I want to be free to rename files, split files, move things around, delete stuff, rename stuff, change formats and structs and functions and API. Not something that SVN (or GIT or even Perforce) would be happy with, even if we did use branching.
I don't agree Dbug. I think this is a case of you not knowing what to do with the repository tool. Do you honestly have the position that your style of operation is *not* something that a source control tool can handle? Because: this is *precisely* what these tools are for in the first place - so you can create a branch, tag it, make new experimental features, and not interfere with the state of the mainline sources - which is *not* what you've done now. You have actually messed up the mainline point of the repository, by adding fw_dbug cruft. This should just be a tag so that those of us who do use source control tools properly, can merge easily, discard easily, ignore or follow your work - easily.

As it stands right now, I have to do a manual diff between fw/ and fw_dbug/, with tools that *aren't* my standard repo tools (svn), before I can easily comfortably manage further changes. That you cannot see the harm of this, is the *only* reason I'm repeating myself, because - while your changes and skills are valuable, screwing up the repository and not using standard source control techniques, especially this early in the game, is simply un-productive. It has a negative effect on those of us who would like to contribute - if your changes were a branch, I could select and merge and create a more robust HEAD of the repository, for all of us to use, than currently stands right now.

I think you don't know what you're doing with the source control tools - and I accept that may be difficult. I'm willing to help. But if you are going to continue operating on the basis that its okay to pollute the repo with manual forks, without giving us the tools to manage this properly, then I have to say it, Dbug: that sucks.

User avatar
barnsey123
Flight Lieutenant
Posts: 379
Joined: Fri Mar 18, 2011 10:04 am
Location: Birmingham

Re: Cumulus Firware Compilation

Post by barnsey123 » Mon Jan 27, 2014 3:57 pm

I have a comfortable chair, some popcorn and a tin-helmet. I think they will come in useful... :wink:

User avatar
ibisum
Wing Commander
Posts: 1024
Joined: Fri Apr 03, 2009 8:56 am

Re: Cumulus Firware Compilation

Post by ibisum » Mon Jan 27, 2014 5:16 pm

I'm not trying to start a flame war or upset anyone, I just think DBug can do better in this situation, to allow a community to manage his contributions better.. I'm pretty serious though, this fw_dbug/ pollution is a problem for me - before I can viably contribute to Cumulus, I have to do a manual diff of his changes from one copy of the source, merge in the *clearly useful contributions*, and only then can I safely - as a developer with 20 years of experience with source control - and comfortably, move on with adding features.

Don't take offense, DBug! I will help you with understanding source control if you want it! I just really think we should be *using* source control to solve the problems you state, instead of avoiding it.

User avatar
Dbug
Site Admin
Posts: 2724
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Cumulus Firware Compilation

Post by Dbug » Mon Jan 27, 2014 6:05 pm

My firmware is gone.
Have fun.

User avatar
ibisum
Wing Commander
Posts: 1024
Joined: Fri Apr 03, 2009 8:56 am

Re: Cumulus Firware Compilation

Post by ibisum » Mon Jan 27, 2014 7:51 pm

Thanks. Much cleaner.

Godzil
Squad Leader
Posts: 758
Joined: Sat May 21, 2011 7:21 pm
Location: Between UK and France
Contact:

Re: Cumulus Firware Compilation

Post by Godzil » Tue Jan 28, 2014 11:06 am

I don't understand what Dbug did was a branch of the official FW, and the way SVN work does that you can branch to any folder you want, so you can ask SVN to do a diff on whatever folder you are using, it does not care if it is a /branch/blah or /trunk/fw_dbug svn does not really know what a tag, branch means they are all folder for him.

I didn't follow how dbug create the fw_dbug folder, and since his fw is not for general use it's normal to have it in another folder, and since his fw is not a real branch of the whole repository puting it aside of the official fw is not bad per se, and could be usefull as his fw may interest some people that does not like/want the official fw.

If you prefer dbug may call is version as fw_alt and this is *NOT* to be the official firmware.


And definitely doing a

svn diff fw fw_dbug

is something that is normal and valid for SVN even if dbug did not use a svn copy to create the fw_dbug folder.

Never forget that Subversion is a versioned "filesystem" (with some lazy copy) and it does not understand what a branch is.

That's a pity to see thing going this way.

User avatar
ibisum
Wing Commander
Posts: 1024
Joined: Fri Apr 03, 2009 8:56 am

Re: Cumulus Firware Compilation

Post by ibisum » Tue Jan 28, 2014 12:36 pm

I agree that this is a regrettable situation (DBug being miffed by my communication, and not contributing as a result, is bad for us as a group), but I also do think if there are going to be multiple contributors to the firmware (and it looks like there are more than just me and DBug who want to contribute) we might want to consider moving to git - so that such issues as this are a lot easier to manage.

From my perspective, the changes DBug made are 95% useful to most all of us - and so there is no reason to make a branch in the first place. As I could easily work with his changes myself, and build upon them also, I would not have complained if he'd added the features to mainline and just checked them in - with a README entry of course, for those of us who won't like having his reset change effect our work progress.

But its always the same with open source projects - you either sort it out as a group to work together, or you get a forking mess. I really hope we don't get forks, this stage in the game, and rather - branches - which can easily be merged. As a volunteer to maintain the firmware, and add features, I hope we can work it out amicably so that there is a clean solution. My personal opinion though, is the fewer forks we can promote, the better.

User avatar
Dbug
Site Admin
Posts: 2724
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Cumulus Firware Compilation

Post by Dbug » Tue Jan 28, 2014 1:06 pm

Let's summarize:
  • I did not use the SVN branch/tag whatever feature, because the point of doing that is to be able to merge back and forth between the development branch and the source branch (or trunk). (This works with the full content of the branch, you can't just cherry pick a feature. )
  • I had no intention to merge anything back to the main firmware, because I was experimenting, plus that was only two days hacking during the week end to see how things were, and how easy it was: Ie, it's crap and barely tested code.
  • Since apparently the main issue was that I was 'polluting' the depot, I will put it back but in my user folder where people can take a look at it if they want.
  • And yes the point is that it's not an official firmware: the quality of the changes are not validated, and there will be much more important fixes to do before my small UI tweaks: Like making it recognize SD cards of all formats, the eventual timing issues on the emulation itself, storing preferences, possibly detecting/supporting the two versions of the display driver in an unique firmware, etc... which will take room and will dictate how much creativity we can have for the rest (don't remember the WHOLE firmware can't be more than 64 kilobytes)
And finally about using the advanced features of SVN, no I don't want to use them for a reason: Some of the persons here on the forum have never used a source control system before, and are just able to do commit/update using a UI, so asking them to be able to cherry pick tags and versions just complicates things for no reason.

I know that you can use history to fetch any version, but reasonably it would be much easier to just have
CUMULUS_0.5.BIN
CUMULUS_0.6.BIN
etc...
than having a single CUMULUS.BIN with revisions (if only because it means they will appear as different files in the web interface which will make it easy for people to download whatever version they want).

Post Reply