Cumulus firmware rework task force

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.
Godzil
Squad Leader
Posts: 774
Joined: Sat May 21, 2011 7:21 pm
Location: Between UK and France
Contact:

Cumulus firmware rework task force

Post by Godzil »

Hi everyone,

As most of you know what the Cumulus is, I will not explain, if you don't, please just look in this forum there are nice topic on it.

Current cumulus firmware works, or works in most situations, but there are still a few quirk and bugs. The UI is not the best we can expect there are a lot of usability issue, and the UI cause a lots of slowdown in the firmware, we also have some bug in the SD management that need to be solved.

The goal of this topic is to discuss and list all the new things that need to done, the bug that need to be solved.

This topic is ONLY about the firmware only, any hardware bugs or feature are not part of this topic.


I've stated to work on making the UI a bit more clean, and thinking about how to make the interface more easy to use.

Let's start with some of my own conventions:

The main interface is composed of 5 buttons and the screen.
There is two button on the left, three on the right, and I will call them from top to bottom and left to right

TL (top left), BL (bottom left), TR (top right), MR (middle right) and BR (bottom right).
Currently what theses buttons provide is really messy.

Next I'm showing you some mockup of what the interface could me (they are really early mockup):

Main screen:
NewCumulusUI_home.png
NewCumulusUI_home.png (621 Bytes) Viewed 13047 times
The idea is quite simple. On this main screen, each button TL, BL, TR, BR that belong to a "corner" (expect for TL) will display a menu related to the drive on the same corner. The MR button will display the cumulus main menu.

Menu sample:
NewCumulusUI_menu.png
NewCumulusUI_menu.png (1.05 KiB) Viewed 13047 times
In the menu display, the TR is used to go up in a menu, BR to going down, and MR to select.

BL would be used for going back in the menu hierarchy, or if we are at the menu top level, go back to the home screen.
TL button will me a user definable button, so that the user could select the function to assign to this button. It could be a "Oric Reset" or "Eject all drive" etc.. The list of option need to be defined.

We can also do the same for the BL button, that by default do a back, but could be customised by the user.

All menu should provide a way to go by in the menu hierarchy anyway.

So we should have at least two types of menu, the drive menu, and the system menu.

The drive menu is the same for all drive, but what we select with it will change parameter for the specific drive selected on the home screen.
The system menu will allow to set parameter of the cumulus itself, like the screen contrast, screen backlight level, the number of drive we want to emulate (from 1 to 4)

Maybe if we want the cumulus to force, or not, a disk boot like the microdisk does (this would allow to not directly boot the Oric on the DOS and get the basic prompt without inserting a floppy) (not sure if this is feasible with current CPLD code.)

Also all drive/cumulus parameters should be saved on the currently used SD card, so that we can have different parameter on different SD card.

Also, the home screen should display more information that the mockup currently display, like the filename of the inserted floppy, maybe the CHS information.

I also integrate in this taskforce something that we discuss with _DBug_ about adding extensible metadatas to the DSK file format, so that we could add thumbnail for example, or information like the name of the compagnie who made the software etc.. Of course all of this should be available to display on the Cumulus, but not edited.

More to come later..
Last edited by Godzil on Thu Jan 29, 2015 5:15 pm, edited 1 time in total.
Godzil
Squad Leader
Posts: 774
Joined: Sat May 21, 2011 7:21 pm
Location: Between UK and France
Contact:

Re: Cumulus firmware rework task force

Post by Godzil »

No one is interested to discuss about this task? :(
User avatar
Dbug
Site Admin
Posts: 4438
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Cumulus firmware rework task force

Post by Dbug »

I am, but a combination of overtime and gamejam made me have no time to think about it.
Also, I wanted to see people opinion about the menu system, which features they would like to have, etc... :)
User avatar
Hialmar
Flight Lieutenant
Posts: 349
Joined: Tue Mar 04, 2014 11:25 am
Location: Toulouse, France
Contact:

Re: Cumulus firmware rework task force

Post by Hialmar »

All this looks awesome to me. Too bad that I don't have a Cumulus :(
Hialmar
CEO and Silicium member.
User avatar
Chema
Game master
Posts: 3013
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: Cumulus firmware rework task force

Post by Chema »

Hi guys. Sorry for my recent inactivity. I also had a bit of overwork and other matters that kept me busy.

I hope in the next few days I'll have some more free time to participate in this discussion. As a first idea I wonder if it would not be a better approach to first make an initial revamp just solving the main issues in the current UI. I really like its simplicity, it does not use a lot of memory, it is quick and could be made easy to use with just minor changes, imho. Currently the usage of the buttons is not consistent and some options (like the reset oric) are not easily accessible.

If this could be solved quickly, we would have more free memory to add options that could be nice to have: such as inserting a blank disk image in a unit, or adding support from commands from the Oric.

And there are still issues to be solved such as the SD and FAT16 support (I am on it, and I think I found something... just gimme some time!).

It could be more realistic to work on a 1.0 version including all this and then work on a nicer graphical UI once we really know the free memory we have.

Just my 2 cents. If you feel with enough energy as to work on a much more ambitious project, then that'd be great!
User avatar
iss
Wing Commander
Posts: 1637
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Cumulus firmware rework task force

Post by iss »

Hi all,
I'm ready to help.
I like both approaches - to improve GUI and to make full rework - no matter in which order.
Just I don't feel myself confident enough to give my opinion about the GUI design.
I'm OK with the current UI, but Godzil's mock-ups are promising something better :).

As you may already know I have 2 not working Cumulus's by me (mine and jorodr's one)
and my first priority is to fix them - meanwhile I can test and debug any proposed changes in sources -
this would be fun and not a problem at all for me.
User avatar
ibisum
Wing Commander
Posts: 1643
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: Cumulus firmware rework task force

Post by ibisum »

I'm interested in helping, but not at all interested in re-do'ing the GUI .. my principle focus will be on figuring out how to control the Cumulus from the Oric, which requires a bit of homework on my part .. the idea would be to add commands like:

!LSDSK - returns a list of .dsk files found on disk
!MOUNTDSK - mount a .dsk file
!UMOUNT - umount a .dsk
!NEWDSK - create a blank .dsk file

.. and so on. I think that this should be a priority because it allows software control over the filesystem, and this in itself can open the door to entirely new classes of application to be written for the Oric .. imagine a game that can arbitrarily mount new volumes as needed ..
Godzil
Squad Leader
Posts: 774
Joined: Sat May 21, 2011 7:21 pm
Location: Between UK and France
Contact:

Re: Cumulus firmware rework task force

Post by Godzil »

Chema wrote:Hi guys. Sorry for my recent inactivity. I also had a bit of overwork and other matters that kept me busy.

I hope in the next few days I'll have some more free time to participate in this discussion. As a first idea I wonder if it would not be a better approach to first make an initial revamp just solving the main issues in the current UI. I really like its simplicity, it does not use a lot of memory, it is quick and could be made easy to use with just minor changes, imho. Currently the usage of the buttons is not consistent and some options (like the reset oric) are not easily accessible.

If this could be solved quickly, we would have more free memory to add options that could be nice to have: such as inserting a blank disk image in a unit, or adding support from commands from the Oric.

And there are still issues to be solved such as the SD and FAT16 support (I am on it, and I think I found something... just gimme some time!).

It could be more realistic to work on a 1.0 version including all this and then work on a nicer graphical UI once we really know the free memory we have.

Just my 2 cents. If you feel with enough energy as to work on a much more ambitious project, then that'd be great!
You're arguments are correct, my feel is that updating the current UI to take less memory and CPU, will just make us creating a new code, so why not change the visible part at the same time? Of course we may not release a one big update that solve everything, but this could be incremental update, with each stable version we get during the development.

From my own experience, if we start by just solving the current bug we will never solve or add new functionality, we should do both at the same time, but not necessarily release both at the same time, this is because it's a community project, not our job, so it only depends on motivation, and as we are not paid, motivation is not infinite, if we put things in the stack of "to do later" it will never be done.

Maybe I'm overconfident, but my proposal is based on things I already done, I already have working code (not on the cumulus) for the menu system I propose, and it would be quite easy to port, even if it may need optimisations. The most difficult part will be to completely decorrelate the UI with the floppy emulator, and give the floppy emulator the highest priority, and from what I saw, without major rework, the current UI can't do this.

One possible option, it seems that FreeRTOS can run on some PIC18, I will take a look at this as it will simplify a lot the overhead and difficulty on making decorrelated tasks.
Post Reply