Development of Blake's 7 (was OASIS development)

Want to talks about games you like, would like to see developed on the Oric, it's here.
User avatar
Chema
Game master
Posts: 2016
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: Development of Blake's 7 (was OASIS development)

Post by Chema » Tue Aug 29, 2017 4:52 pm

Symoon wrote:
Mon Aug 28, 2017 11:00 pm
Here's what I read in Sedoric à Nu from André C.:

Sector identification: 12 bytes at [#00], [#A1 #A1 #A1], [#FE pp ff ss tt CRC CRC] then 22 bytes [#4E].
(note: pp=track, ff=side, ss=sector, tt=size of sector (1 for 256 bytes, 2 for 512, ...))
Data id: 12 bytes at [#00], [#A1 #A1 #A1], [#FB] then 256 bytes of data.

I'm certainly not teaching you anything there, but is it normal you use bytes at value 22 instead of 4E?
Well, you could teach me a lot, as all this disk format stuff is rocket science for me! I was aware, however, of this discrepancy and I have absolutely no idea why FloppyBuilder (and other tools maybe?) use 22. It seems to work, however.
Symoon wrote: EDIT: don't forget there are 3 different RAM patterns in Euphoric, 0, 1 or 2 IIRC!
I forgot :) I will try ASAP. Have not seen any evident uninitialized var so far... :(

About the speaking sounds... I made a first attempt in C. My sfx player is too slow for this. I am using the IRQ at 50Hz and each note takes 7 IRQs when playing SFX. I should hack it so it goes much faster, but without disrupting other SFXs (or silencing them...). And also keeping in mind that the sounds takes long enough for the reader to read the sentence, or, at least, only animate the mouth while the sounds are being played (using IRQs of course).

Maybe using a dedicated routine for playing talk sounds, trying not to destroy my sfx player...

I am nearly convinced, but need to make more tests to see the difficulties of adding this feature.

I'd be much more willing to work on this if the game worked with Cumulus!

I also may create a minimalistic FloppyBuilder project which saves data and loads it back checking for errors, to aid in the process (and end up with cleaner loader code for Dbug!).

So more and more work...

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

Re: Development of Blake's 7 (was OASIS development)

Post by Dbug » Tue Aug 29, 2017 6:05 pm

Chema wrote:
Tue Aug 29, 2017 4:52 pm
I have absolutely no idea why FloppyBuilder (and other tools maybe?) use 22. It seems to work, however.
I did not reinvent the wheel, I based the floppy creation code in FloppyBuilder on what was in Fabrice tools, because after all they were apparently working and were used everywhere :)

Maybe somebody who actually understand all this stuff (Symoon volunteered it seems :D) should just look at the code and tell me what to change (and why): http://miniserve.defence-force.org/svn/ ... Floppy.cpp

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

Re: Development of Blake's 7 (was OASIS development)

Post by Chema » Tue Aug 29, 2017 6:39 pm

I don't know why dbug, but if you look at the github repository of Oric tools here , old2mfm.c has this:

Code: Select all

/*                for (i=0;i<gap2-12;i++) trackbuf[offset++]=0x4E;
*/ for (i=0;i<gap2-12;i++) trackbuf[offset++]=0x22;
With no further comment. However, every source about IBM Double Density Format such as this shows they should be $4e.

I have absolutely no idea why. Probably Jede or Fabrice know. Maybe it is just a bug (22 bytes to $4e... you can easily type 22 a second time, instead of 4e), but writedsk ignores this, so real disks work, and most emulators also ignore these gaps and search for series such as A1A1A1FB directly.

The cumulus firmware here seems to ignore the content and just skip 22 bytes, but I think it wrongly writes a sector header with only 6 zeros (as in the single density format) instead of 12:

Code: Select all

// Sector header.
static rom uint8_t sector_header[] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xA1, 0xA1, 0xA1, 0xFB };

...

/* Write sector header to SD Card.
             * 6 zero bytes followed by DAM.
 			 */
			for (i = 0; i < 10; i ++)
			{
				// Write
				CheckWriteTrackEnd();
				TrackWriteByte(sector_header[i]);
				drive->track_position ++;
			}
The effect of this? I don't know. If software tools are prepared to deal with this (they probably ignore the number of zeros and just do a search for the A1 A1 A1 FB, as I said), the answer is none. And several programs write things on disks using Cumulus with no problems.

It must be somewhere else... damn! it is quite frustrating.

User avatar
Symoon
Archivist
Posts: 1150
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: Development of Blake's 7 (was OASIS development)

Post by Symoon » Tue Aug 29, 2017 10:23 pm

Chema wrote:
Tue Aug 29, 2017 6:39 pm
I don't know why dbug, but if you look at the github repository of Oric tools here , old2mfm.c has this:

Code: Select all

/*                for (i=0;i<gap2-12;i++) trackbuf[offset++]=0x4E;
*/ for (i=0;i<gap2-12;i++) trackbuf[offset++]=0x22;
With no further comment. However, every source about IBM Double Density Format such as this shows they should be $4e.

I have absolutely no idea why. Probably Jede or Fabrice know. Maybe it is just a bug (22 bytes to $4e... you can easily type 22 a second time, instead of 4e), but writedsk ignores this, so real disks work, and most emulators also ignore these gaps and search for series such as A1A1A1FB directly.
It looks like a test in the source code. The source code I got for Old2MFM has this too, and the file is from 1998.
I ran Old2MFM.exe on an old disk, and no sign of #22 bytes when I hex edit the DSK file. 4E instead.
So maybe Old2MFM source is wrong, and the .exe is OK. We should delete the line with #22 and restore the commented line?

User avatar
Symoon
Archivist
Posts: 1150
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: Development of Blake's 7 (was OASIS development)

Post by Symoon » Tue Aug 29, 2017 11:09 pm

(Which means, if FloppyBuilder is based on the source code of Old2MFM, that it has to be modified, too... Maybe an explanation for various problems with real disks?)

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

Re: Development of Blake's 7 (was OASIS development)

Post by Chema » Tue Aug 29, 2017 11:22 pm

Symoon wrote:
Tue Aug 29, 2017 11:09 pm
(Which means, if FloppyBuilder is based on the source code of Old2MFM, that it has to be modified, too... Maybe an explanation for various problems with real disks?)
I doubt it, because if I recall correctly writedsk ignores the content of the gaps, so it does not check whether there are 22 or 4e bytes, simply jumps over them. If you create your floppy with writedsk it should work. Mine work :)

Only problem is that the image is not following the standard, which could be a problem if using other tools. I immediately thought of the tool from HxC (the one which converts dsk to hfe) but jede used it and it worked, so probably also ignores the contents of the gap too!

User avatar
Symoon
Archivist
Posts: 1150
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: Development of Blake's 7 (was OASIS development)

Post by Symoon » Tue Aug 29, 2017 11:32 pm

I was thinking about speed problems you had a while ago... Can't recall if it was related to sectors or tracks, but IIRC FloppyBuilder was much slower than a Sedoric disk...
But as you say, if you use Writedisk to create both real disks (Sedoric and FloppyBuilder), and Writedisk overrides these bytes, then that's a red herring!

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

Re: Development of Blake's 7 (was OASIS development)

Post by Chema » Wed Aug 30, 2017 12:01 am

Ahhh, you're right. Two frustrating mysteries with no answer so far...

I will have a look at writedsk code, but I really think it simply skipped the gap, without looking at the contents.

BTW, Jede suggested that you could do a French version of Blake's 7... Beware that:
- I already made a Spanish version and it took me a good number of hours and my free time of weeks to do so, because there is a huge amount of text inside all the resources and strings have a maximum length and so on...
(yeah I wish I could have all the text in one big file, but it is not the case here...)
- I am not sure the amount of extra characters a French version would need... but my compiler currently support coding strings with ñ and accentuated vocals as used in Spanish..

So it would be months of work...

User avatar
Symoon
Archivist
Posts: 1150
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: Development of Blake's 7 (was OASIS development)

Post by Symoon » Wed Aug 30, 2017 6:08 am

Erm, I technically could but not sure I'd have time to... Jede volounteerd for me here :mrgreen:
I began translating Mercenary III 12 (twelve) years ago and didn't finish it yet ^^. Same for Tyrann II, we began with Jim around 2001...

I can confirm translations can be hell, with space contraints, and cultural references.
Of course we can give it a try if there's a huge demand for it, but I confirm anyway it would be months (if not years) before completion ;)

User avatar
Symoon
Archivist
Posts: 1150
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: Development of Blake's 7 (was OASIS development)

Post by Symoon » Wed Aug 30, 2017 6:17 am

Chema wrote:
Wed Aug 30, 2017 12:01 am
Ahhh, you're right. Two frustrating mysteries with no answer so far...

I will have a look at writedsk code, but I really think it simply skipped the gap, without looking at the contents.
If you still have one of those slow physical disks, maybe it could be faster to try and read a complete track on Oric with the latest version of Nibble and see if there are any #22 between the sectors?

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

Re: Development of Blake's 7 (was OASIS development)

Post by Chema » Wed Aug 30, 2017 12:29 pm

Symoon wrote:
Wed Aug 30, 2017 6:17 am
If you still have one of those slow physical disks, maybe it could be faster to try and read a complete track on Oric with the latest version of Nibble and see if there are any #22 between the sectors?
That is actually a good idea. I need to check as soon as I can.

On a side note... is there any tool to make a copy of a disk sector by sector? I'm looking for a way to recommend users of real floppy versions of the game to backup the game disk.

jede
Flying Officer
Posts: 138
Joined: Tue Mar 14, 2006 11:53 am
Location: France

Re: Development of Blake's 7 (was OASIS development)

Post by jede » Wed Aug 30, 2017 2:09 pm

Symoon wrote:
Tue Aug 29, 2017 11:32 pm
I was thinking about speed problems you had a while ago... Can't recall if it was related to sectors or tracks, but IIRC FloppyBuilder was much slower than a Sedoric disk...
About "FloppyBuilder was much slower than a Sedoric disk", could you explain this ? FloppyBuilder must be quicker than sedoric. Anyway, when floppybuilder is used, it usually loads also more data than a sedoric file.

jede
Flying Officer
Posts: 138
Joined: Tue Mar 14, 2006 11:53 am
Location: France

Re: Development of Blake's 7 (was OASIS development)

Post by jede » Wed Aug 30, 2017 2:11 pm

Symoon wrote:
Wed Aug 30, 2017 6:08 am
Erm, I technically could but not sure I'd have time to... Jede volounteerd for me here :mrgreen:
I began translating Mercenary III 12 (twelve) years ago and didn't finish it yet ^^. Same for Tyrann II, we began with Jim around 2001...

I can confirm translations can be hell, with space contraints, and cultural references.
Of course we can give it a try if there's a huge demand for it, but I confirm anyway it would be months (if not years) before completion ;)
I said that because you are the best for translation :) And you did it in some Oric stuff :)

User avatar
Symoon
Archivist
Posts: 1150
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: Development of Blake's 7 (was OASIS development)

Post by Symoon » Wed Aug 30, 2017 3:40 pm

jede wrote:
Wed Aug 30, 2017 2:09 pm
Symoon wrote:
Tue Aug 29, 2017 11:32 pm
I was thinking about speed problems you had a while ago... Can't recall if it was related to sectors or tracks, but IIRC FloppyBuilder was much slower than a Sedoric disk...
About "FloppyBuilder was much slower than a Sedoric disk", could you explain this ? FloppyBuilder must be quicker than sedoric. Anyway, when floppybuilder is used, it usually loads also more data than a sedoric file.
It's problems Chema encountered a while ago in this thread... He wondered why his disks made by FloppyBuilder seemed much slower than the ones formatted by Sedoric IIRC.
You'll need to read all the pages before to find it back ;)
I'm just wondering if the fact that FloppyBuilder writes value #22 instead of #4E (because of the possible Old2MFM mistake in the source made available) couldn't be the reason things are slower.

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

Re: Development of Blake's 7 (was OASIS development)

Post by Chema » Sun Sep 03, 2017 2:51 pm

Hi again. Maybe you know from the thread about Floppy Builder, than we finally found the issue. It seems to be a bug in the Cumulus firmware, but the good news is that I think I found a way to circumvent it. Now the saving works in the Cumulus, despite the bug.

I want to make some tests with real floppies but I am quite sure that it will work.

On another matter I have received feedback from one tester about Episode 3. Several typos and small things that I am now correcting.

I also have a first version of the instruction document (with pictures and such things).

So time to resume finishing things for the release :)

Stay tuned!

Post Reply

Who is online

Users browsing this forum: No registered users and 4 guests