Page 5 of 5

Re: FloppyBuilder evolution

Posted: Sat Sep 02, 2017 11:05 am
by Chema
Dbug wrote:
Sat Sep 02, 2017 9:39 am
Nice find.
So technically... it's a Cumulus firmware bug?
Yes, I'd say so. What I'd do is:
-Correct the number of zeros in the header.
-Correct the $22 instead of $4e error
-Correct the loop so it does not produce extra DRQ (inside the loop it should be set DRQ, Pause, read data register, store, decrement counter)
-Probably force a card update (flush) after the write operation is finished.

I wouldn't try to solve the missing handling of BUSY bit nor anything related to the FAT driver. It should work that way.

I'd also take this opportunity to change some more things in the firmware, such as the default protected image thing or the way the Oric is reset.

But I'd try to produce a version of the game which simply bypasses the bug, because not everyone is going to update their firmware... And, besides, who would do it? :wink:

Re: FloppyBuilder evolution

Posted: Sat Sep 02, 2017 6:06 pm
by Symoon
Chema wrote:
Sat Sep 02, 2017 9:22 am
@Symoon give it a try, but no need for you to modify the disk image. Just check what happens to discard it is only a timing issue in my unit.
Ok, it took a while to find back a machine that worked with the Cumulus but finally I could do the test (on an Oric-1!), and... After a few disk flashes, I got the red bar (the disk was unportected).
So it's not just your Cumulus Chema, it seems!

Re: FloppyBuilder evolution

Posted: Sat Sep 02, 2017 7:41 pm
by Symoon
Chema wrote:
Sat Sep 02, 2017 11:05 am
Yes, I'd say so. What I'd do is:
-Correct the number of zeros in the header.
-Correct the $22 instead of $4e error
-Correct the loop so it does not produce extra DRQ (inside the loop it should be set DRQ, Pause, read data register, store, decrement counter)
-Probably force a card update (flush) after the write operation is finished.
Does the Cumulus firmware also implement $22 instead of $4E, of was it just FloppyBuilder?
But I'd try to produce a version of the game which simply bypasses the bug, because not everyone is going to update their firmware... And, besides, who would do it? :wink:
Actually, I never thought about that, but who made the original Cumulus code?
It must have been a huge work, was it Retromaster alone? Or Metadata?

Re: FloppyBuilder evolution

Posted: Sat Sep 02, 2017 9:01 pm
by Chema
I don't remember now if Cumulus writes the $22 but certainly the six zeros.

And it was retromaster who wrote the firmware.

Cheers

Re: FloppyBuilder evolution

Posted: Mon Sep 04, 2017 11:42 pm
by NightBird
Chema wrote:
Sat Sep 02, 2017 11:05 am
But I'd try to produce a version of the game which simply bypasses the bug, because not everyone is going to update their firmware... And, besides, who would do it? :wink:
The Cumulus firmware update seems easy to do?
www.youtube.com/watch?v=WoVpMwnYQIY
Is there a link for dowloading the latest updates?

Re: FloppyBuilder evolution

Posted: Tue Sep 05, 2017 5:43 am
by coco.oric
Normally, on my old notebook, i've all the software i need to compile a cumulus firmware.
If there's a new one, i can try it.

Re: FloppyBuilder evolution

Posted: Tue Sep 05, 2017 7:13 am
by Dbug
Updating the firmware of cumulus is relatively easy, the two difficulties are:
- Compiling the firmware requires a specific toolchain
- You need to compile the firmware twice - one for each type of display -

After it's relatively easy to update the cumulus itself, but you need to use the right firmware, else the display stops working :)

Re: FloppyBuilder evolution

Posted: Tue Sep 05, 2017 8:16 pm
by NightBird
Dbug wrote:
Tue Sep 05, 2017 7:13 am
... you need to use the right firmware, else the display stops working :)
My Cumulus (PCB ID #43) has a black dot on the PCB above the 3 buttons, so a S1D15G10 display.

If there is a new update of the firmware, I can try it too!

Re: FloppyBuilder evolution

Posted: Tue Sep 05, 2017 8:24 pm
by Chema
I had the toolchain setup and made some tests, but I changed my hard drive since, and now all that is lost (the old HD simply broke down :( ).

There is a list of things that should be done to the firmware, and there was some enthusiasm to do so at the beginning, but soon after everybody disappeared and nothing was really done (me included, I was working on the support of old SD cards, with no success).

Apart from this bug, we badly need some redesign of the UI, so you don't have to press so many buttons to load a disk and reboot, images are not write-protected by default, and the general usability improves a bit.

And that not counting the idea about moving the critical code to interrupt service routines and keeping UI as background task, updating things only when there is time to do so :/

Re: FloppyBuilder evolution

Posted: Sun Nov 05, 2017 9:13 pm
by Chema
Hi all!

With the enormous help of Fabrice Frances (he is doing the work, really) I am not only improving the disk routines in FloppyBuilder ()and therefore, in Blake's 7) a lot, but also started working on supporting the Jasmin.

The new routines in Microdisc are so robust that you can pull out the disk while loading and put it back in, and the loading resumes.

And, at last, after a huge effort, the game booted on Jasmin under emulation!!! It does not mean it works on real hardware, as the bootsector needs tweaking and several corrections, but it is a good start. Also writing should be added.

But I now understand where the problem was, and supporting both Microdisc and Jasmin on the same disc is very possible :)

The biggest problem is that I don't have a Jasmin unit with a real floppy to test... So if anyone has it and is willing to make some tests for me, raise your hand.

Re: FloppyBuilder evolution

Posted: Mon Nov 06, 2017 1:16 pm
by Chema
Alright, the game now works (tested only under emulation) with both Microdisc and Jasmin :D

It boots, works, saves and loads on both systems. I still need to test it with real drives and floppies, as well as with Cumulus, because several routines had to be rewritten. Current code is in the repository.

I think I also kept the correct alignment when accessing registers, so it should work even with the Telestrat bug.

Now I need to test in a real Jasmin drive, but I don't have one... Anyone willing to do the test for me?

Re: FloppyBuilder evolution

Posted: Mon Nov 06, 2017 8:04 pm
by Symoon
Chema wrote:
Mon Nov 06, 2017 1:16 pm
Now I need to test in a real Jasmin drive, but I don't have one... Anyone willing to do the test for me?
If he ever has time, I think Jede is your best luck (now is that denouncing a friend? :mrgreen: )
Last time I plugged my Jasmin 2, it didn't work and ended up smoking... Since then it's shelved in a croner, waiting for a kind hardware master to have a look at it (next Oric meeting maybe).
I also got a Jasmin 1, but at my parents', where I won't be before a while...

Re: FloppyBuilder evolution

Posted: Wed Nov 08, 2017 7:12 pm
by Chema
Jede, unfortunately, does not have his unit operative :(

In any case the routines are now working for saving and loading with correct error checking (I pulled the disk out while writing, and back in and it saved the game properly :mrgreen: and worked for Microdisc (my unit with real FDD) and Jasmin (emulation with Oricutron and Euphoric). All accesses to FDC registers are aligned so the code should work on the Telestrat, although the disk won't boot directly on that machine.

Still working on that, but routines are now quite definitive, but for the disk picture and color flashing, which should be put externally to the loader code to make it more general.

You can see them in the floppycode folder in Blake'7 sources in the repository.

Re: FloppyBuilder evolution

Posted: Wed Nov 08, 2017 7:34 pm
by Dbug
I guess when we have this fully functioning version it will become the reference implementation of the loader system, which means I'll use it as the base for the updated OSDK sample project, which I guess means I'll have to make some small application that allows loading and saving of stuff.