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
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Cumulus Firware Compilation

Post by Dbug »

You may have the different type of driver.
In 6610.h check these two defines:

Code: Select all

#define PCF8833
//#define S1D15G10
Try to comment them the other way.

There are two type of visual display on the Cumulus hardware, and they require different code.

Ideally one should be able to build both in the same firmware and auto-detect, but that means using more code.
User avatar
coco.oric
Squad Leader
Posts: 720
Joined: Tue Aug 11, 2009 9:50 am
Location: North of France
Contact:

Re: Cumulus Firware Compilation

Post by coco.oric »

Yep, it works fine.
My 0.51 trial modification is working.
And your 0.8 version is working too.
Thanks
coco.oric as DidierV, CEO Member
Historic owner of Oric, Apple II, Atari ST, Amiga
Godzil
Squad Leader
Posts: 774
Joined: Sat May 21, 2011 7:21 pm
Location: Between UK and France
Contact:

Re: Cumulus Firware Compilation

Post by Godzil »

It not possible to auto detect the screen type, we need either to store it somewhere in a non volatile area, or ask the user at first start to select the correct displaying screen mode. I have an idea about this, but it will need to wait for having my own one ;)
User avatar
metadata
Pilot Officer
Posts: 114
Joined: Wed Aug 31, 2011 7:59 pm
Location: Hildesheim, Germany
Contact:

Re: Cumulus Firware Compilation

Post by metadata »

The correct LCD driver for each board is also in the bootloader. Maybe we can use it for the firmware too.
I marked the boards this the S1D15G10 LCD with a black dot on the PCB above the buttons.
User avatar
Chema
Game master
Posts: 3014
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: Cumulus Firware Compilation

Post by Chema »

Has anybody advanced with the firmware? Ibisum? I am no expert, but I've seen the code, a quick glance, I admit it, and noticed the disk commands are not interrupt driven. The main loop just tests if there is a command to handle and if not, updates the UI. If updating the UI takes too long, this could result in a delay.

In addition, as Dbug pointed out to me, some disk operations update the UI while doing their work, which could be a slow operation. This could result in unexpected delays or too tight timing, which could be problematic.

When I tried to measure the read/write timings, I noticed they were quite variable on the cumulus.

It would be great if someone with experience programming this kind of devices gave it a look...
User avatar
ibisum
Wing Commander
Posts: 1645
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: Cumulus Firware Compilation

Post by ibisum »

Alas, I have had little time to look into the Cumulus firmware these past few weeks, due to real-work deadlines being pretty intense .. but I've definitely got it on my list of things to do in my next round of free time. I'd love to sort out the polling/versus-interrupt-driven issue - this seems quite a weak point. At least the existing code demonstrates whats possible, but it sure does seem to me that it should be a bit more robust.
User avatar
Chema
Game master
Posts: 3014
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: Cumulus Firware Compilation

Post by Chema »

Is anyone finally having a look at the firmware code? After using Cumulus for a while I really think a different user interface would be great!

I might give it a look, but would not like to start working if somebody has advanced in this....
User avatar
ibisum
Wing Commander
Posts: 1645
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: Cumulus Firware Compilation

Post by ibisum »

I have it unpacked and set up but I haven't been able to upload a locally-built binary .. last I looked, I still had to find a way to do that. I'm quite happy to work with you on features, though .. the most important thing from my perspective is to figure out some way to be able to control Cumulus from the Oric itself .. this might be tougher than I think .. but I don't know yet. I need to finish setting up so I can build and run.
User avatar
coco.oric
Squad Leader
Posts: 720
Joined: Tue Aug 11, 2009 9:50 am
Location: North of France
Contact:

Re: Cumulus Firware Compilation

Post by coco.oric »

Hello,

I've looked at it last year (in february)
I 'll be happy to work with you on it. the main difficulty is to define an interface with the 5 buttons. It's not simple to keep the same logic on all menus.

I'll search about my notes and send it to you.
coco.oric as DidierV, CEO Member
Historic owner of Oric, Apple II, Atari ST, Amiga
User avatar
iss
Wing Commander
Posts: 1641
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Cumulus Firware Compilation

Post by iss »

I'll be happy to join the party too. :)
Here is my experience:
I successfully compiled PIC firmware and programed cumulus - this fixed 2 cumuluses (mine and jorodr's one) after trying to connect them to Pravetz-8D. Under "fixed" I mean display, buttons and SDcard interface are working as expected, but when connected cumulus makes Atmos to freeze with vertical B/W stripes.
I successfully compiled Xilinx jed file after fixing some obvious bugs. Successfully dumped the contents from Xilinx chips of both cumuluses and compared them - they are equal! Successfully programmed Xilinx again with the compiled from sources jed file. Unfortunately both cumuluses still not work - B/W stripes on power-on.
User avatar
Chema
Game master
Posts: 3014
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: Cumulus Firware Compilation

Post by Chema »

Do you mean the Xilinx code we have is not correct? Anyway if you managed to correct it and get a good source of the current one, then it is a start. I think the part about rising edge detection was not really robust...

Anyway I was thinking about the pic code, with the UI. I think we should put all the part regarding reading and writting in an interrupt service routine. The code that updates the screen takes quite a lot of time and there may be some issues there.

Also the procedure to insert a new image and reset the Oric is a bit too long, the usage of the buttons is not consistent and so on...

BTW is there a way to create an empty image to format and work with?
User avatar
Dbug
Site Admin
Posts: 4444
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Cumulus Firware Compilation

Post by Dbug »

Imo, one of the most important thing would be to find a way to get the UI code to run with lower priority, perhaps in some thread or something like that. I have no idea about what these small devices can do, but what's sure is that updating the display has a terrible impact on the performance.

On my version of the firmware I added the display of the currently read track and sector - I needed that to debug my FDC loader code -, and that was perceptibly impacting the read speed of the Cumulus.

The UI should be totally asynchronous, and update the screen "when it can" :)

And yes, the UI code takes also a lot of room, that's one of the things I was trying to solve, by factorizing code.

The second important thing would be to manage to save settings, because that would make it possible to have the same cumulus firmware behave differently depending of the needs.

Typically there are two main usages:
- Floppy drive user who want to be able to search and find floppy files efficiently, which is not really doable with the current UI because the page refresh is slow and there's no way to select floppies by categories or name, etc...
- Developer, who want to be able to update the same DSK file again and again (which is what I did on my version of the firmware, with a "Reset and Reload" key combination.

If we could save settings, we could have a preference page and swap between different usage modes with the same firmware.
User avatar
ibisum
Wing Commander
Posts: 1645
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: Cumulus Firware Compilation

Post by ibisum »

I really think it should be more of a priority to try to get Cumulus controllable from the Oric - this then renders the UI not as important, and we can move on to fixing the UI issues after this. I imagine having some sort of command like "!CUMULUS VOLS" to get a list of .DSK files available, and then "!CUMULUS MOUNT somefile.dsk" to mount it, and so on .. But the trouble is I don't have enough understanding of how this might be accomplished - someone else mentioned a while back that it was feasible and quite possible, but alas I don't know enough about how the Oric would run these commands ..
User avatar
Chema
Game master
Posts: 3014
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: Cumulus Firware Compilation

Post by Chema »

I agree with Dbug. The way to do this is making the disks operations interrupt-driven. The main task could update the UI with the current sector or whatever other info which could be held in global variables. I've nver sone this, but it should be quite easy.

This and some updates to the UI So it is easier to use could be a first step, imo. I remember some tests which showed quite highly variable timings for sector reads and writes, and this could be a source of problems.

Controlling the cumulus from the oric would be great, but I don't think it is the main need for now. It could be done, I assume though I don't know the cumulus internals, by asking to read or write invalid sectors and, instead of returning an error, returning data to the Oric or doing something such as mounting an image or so.
User avatar
Chema
Game master
Posts: 3014
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: Cumulus Firware Compilation

Post by Chema »

I've been having a look at the Cumulus sources (not too deeply, anyway). Just some random ideas:

The main loop does:

Code: Select all

	while (1)
	{
		/* See if a command request has arrived */
		if (PORTBbits.RB0 == 0)
		{
			/* So handle it */
			ui_wd1793_command_active();
			wd179X_handle_command_request();
			ui_wd1793_command_done();
		}
		else 
		{
			/* Do UI Stuff */
			ui_run();
		}
	}
The ui_run() simply takes care of user input through the Cumulus buttons and it is not done until any pending command has been handled. Certainly the PORTBbits.RB0 could be assigned to an interrupt, so an ISR may serve commands whenever the Oric asks for them to avoid delays, but I think this is not creating problems as you don't usually do anything while the disk is being read/written.

The apparent delays may come from the fact that the commands do update the UI, log events, etc. This seems that could be a lengthy process and could be the reason why read/write operations have quite variable timings (if they do, as I think, anybody experienced this?). Maybe the efforts could concentrate on solving this then (if you think this is an issue, that is). One possibility would be to defer screen updates (such as sector/track number display). If the command handling is set as interrupt driven, the above loop could be altered with something such as:

Code: Select all

	while (1)
	{
		if (UI needs updating)
		{
			Update UI with sector/track number, log,...
		}
		/* Do UI Stuff : User inputs*/
		ui_run();

	}
And the command handling routines may just drop the values to display in global variables, for instance, and signal that UI needs updating.

This has a clear drawback (or two): Type III commands which read/write full tracks and addresses (don't know what this is) will not show these values onscreen. We could leave the blinking of the small square indicating activity and maybe other visuals inside the command handling if they don't take too much time.

Or we can leave things as they are now. In fact it is working...

Another thing is about communicating from the Oric to the Cumulus. The FD179x has 11 different commands. It is possible to use any invalid command to broaden the possibilities. For instance any command whose bits are 11111xxx is invalid. It is possible, therefor, to implement extended behaviour in the Cumulus by creating new commands. Whenever a new command is detected, the track and/or sector registers may be used to indicate extra information.

This way it could be possible to implement commands on the Oric side which could ask the Cumulus to send the directory information, select a disk image, mount it, reset, etc. I am sure you can imagine the possibilities... even a whole new OS.

But yeah, it would only be compatibe with Cumulus and I am not sure about the amount of memory that it would require on the PIC.

I still think this is an interesting project, but it is complex. In fact we have not found a solution to store tape based games on disk (at least not all). A program which loads a memory dump created with an emulator and stored in a disk file into the Oric would be much more practical. And it could be done with the Cumulus as it is and would be compatible with Microdisc too.

As I said, just some random thoughts...
Post Reply