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

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

Post by Dbug » Thu Mar 15, 2018 2:37 pm

Maybe worth contacting someone on an Atari forum, to ask for a hand - and at the same time see if such a card can dump Oric disks ;)
I contacted the HxC author with a link to the forum post, and he answered something (google translated) like that:
Apart from a formatting issue (gap, track skew, different interleave ...) I do not see what could explain that.
If you have floppy streams from a Kryoflux or SCP card, you can use the HxC software to view the floppy disk content graphically.

User avatar
Chema
Game master
Posts: 2247
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 » Thu Mar 15, 2018 7:14 pm

Yep I am confused too. There must be something stupid I am not seeing.

I used readdsk today to dump the contents of the DD and the HD disks, just in case writedsk2 was doing something strange with the interleave. After all it relays on go32_dpmi to format tracks and write sectors.... In any case both images are exactly the same and contain no interleaving. Guess what? They are the same because readdks reads sectors in order 1,2,3,... not as they appear on the track (of course).

So no info can be extracted this way... Just so you don't lose time.

We need a way to inspect the disk contents with other kind of tools.

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

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

Post by Dbug » Thu Mar 15, 2018 9:32 pm

Chema wrote:
Thu Mar 15, 2018 7:14 pm
We need a way to inspect the disk contents with other kind of tools.
That's why there are all these devices: Kryoflux, Catweasel, etc... which are designed to read floppy content at the lowest possible level by using their own custom controllers which are custom controlled, so they can emulate and read any time of floppy format known to mankind.

It's commonly used by people who archive software in order to get binary perfect files, including protections and all weird artefacts.

User avatar
Chema
Game master
Posts: 2247
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 » Thu Mar 15, 2018 10:37 pm

As a side note, it is not that the disk is being written as high density, because if I remove the tape covering the hole write2dsk fails completely

User avatar
iss
Squad Leader
Posts: 620
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

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

Post by iss » Thu Mar 15, 2018 10:45 pm

Chema, what model is your Oric floppy? Else I guess you are using Silicebit's controller, right?

User avatar
Chema
Game master
Posts: 2247
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 » Thu Mar 15, 2018 10:54 pm

Uf, not sure. The floppy is an old SAMSUNG, IIRC... so old it has a switch to select DS0-3 (not even a jumper). The controller, yes... it is Silicebit's Microdisc clone.

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

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

Post by Symoon » Fri Mar 16, 2018 3:43 am

Chema wrote:
Thu Mar 15, 2018 10:37 pm
As a side note, it is not that the disk is being written as high density, because if I remove the tape covering the hole write2dsk fails completely
Though I don't belive it much myself, I'm still wondering if it can't be something related to density.
Removing the tape to write gives errors. But what happens if you write with the tape, then read without the tape? Does it fail?

If it doesn't fail, that means that the taped hole affects something at writing, but doesn't affect the reading. So maybe you wrote at DD speed (250kBps, hole taped), but what speed was used for reading, DD of HD (500kBps for HD) as the hole is ignored?

OK, it seems unlikely, and I guess it could be tested on a PC too... Writing a fake DD then testing reading speed, compared to a 100% DD disk reading speed.

User avatar
Chema
Game master
Posts: 2247
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 » Fri Mar 16, 2018 8:18 pm

Okay, mystery solved, thanks to Fabrice. He pointed me out that writedsk2 does NOT format a track if writing does not fail, so if a disk has been used for the Oric before, the interleaving is not maintained.

I am not sure why it behaves this way or what are the conditions, but I used Nibble and verified that the slow disks did not have the interleaving, while my HD disks (never used before for Oric) had. So I took one DD disk, formatted it under MSDOS and used writedsk2 again, and the loading was as fast as with the HD disks in the video.

I really think that writedsk2 should have an option to format the track before writing every time, because this is quite annoying!

So, that was it. I knew it should be something stupid along that line.

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

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

Post by Dbug » Fri Mar 16, 2018 8:24 pm

So the bottom line is: Yes interleaving does work and has a noticeable impact on the loading times :)

Now the question is: Are we sure that 5 is optimal?
Could you format another floppy, and then write with interleave 4 or 3 to test and see if it gets faster or slower?

Also, has anyone tried the version of FloppyBuilder 1.2 I attached earlier on this thread so I can push a new OSDK out?

User avatar
Chema
Game master
Posts: 2247
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 » Fri Mar 16, 2018 8:39 pm

hehe No. I did not test any other interleaving factor. The theoretically optimal was 3, but it was a bit too close, so 4 should be better. I really have to test, but in any case the speed now is nearly the one in the emulator, which is great!

Also I did not test the floppybuilder version you posted... I have version 1.001 what are the changes?

We also could talk about the changes in the loading and loader code, because it is now cleaner and supports Telestrat (does not boot, but works) and Jasmin, but they need some cleaning, normalizing. You can see the changes I made in the Blake'7 sources in the repository.

I have asked Fabrice about the possibility of adding an option to writedsk2 so it formats each track before writing. I really think that should be the default behavior.

EDIT: Just tested and it seems to work, produces a correct disk (tested on the emulator) with the correct interleaving (checked with an hex editor) :)

Anything else I should check?

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

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

Post by Dbug » Fri Mar 16, 2018 8:50 pm

This version also fixes the CRC and 0x4E / 0x22 gap2 values.

If it works for you, I'll push a new OSDK tomorrow :)

User avatar
iss
Squad Leader
Posts: 620
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

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

Post by iss » Fri Mar 16, 2018 9:11 pm

iss wrote:
Wed Mar 14, 2018 9:42 am
... the interesting part: writedsk2 first tries to write the sectors and if the operation fails then it formats the track and repeat the writing...
He, I was close in my guess, "just" my conclusion was wrong :). Anyway, it's easy to change writedsk2, so it always first formats the track with the interleave from input image - I'll try to make it, but I need first to install the right compiler.
About the new FloppyBuilder - the compilation under Linux/GCC fails in Floppy.cpp in line #398:

Code: Select all

Floppy.cpp: In member function ‘bool Floppy::LoadDisk(const char*)’:
Floppy.cpp:398:25: error: cannot bind non-const lvalue reference of type ‘void*&’ to an rvalue of type ‘void*’
   if (LoadFile(fileName,(void*)m_Buffer,m_BufferSize))
                         ^~~~~~~~~~~~~~~
Removing the typecast (void*) solves the issue, i.e. change to:

Code: Select all

 if (LoadFile(fileName,m_Buffer,m_BufferSize))
BTW, another good option to play with interleave is SAMdisk (it's already discussed in the forum)....

User avatar
Chema
Game master
Posts: 2247
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 » Fri Mar 16, 2018 9:28 pm

Made a couple of tests with interleaving... 3 and 4 give similar results to 5, so I guess that once the sector is not missed and we have to wait for a full rotation, times get quite close. In fact I could not time any difference (a bit above 6 secs both 3 and 4), but I think that interleave of 3 produced quicker loading, as the floppy icon flickered quicker, but sometimes missed the sector (it was too close...), compensating the overall time, and making it even slower than 4 (or so it seemed to me).

About making writedsk format the track before writing, I think it should be an option (default or not). I asked Fabrice, because I don't want to touch the sources without his approval, but yes, it should be easy to do.

User avatar
iss
Squad Leader
Posts: 620
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

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

Post by iss » Fri Mar 16, 2018 10:05 pm

Attached is the quick hack writedsk2f (source & dos executable). It should always format tracks before writing.
It's only proof-of-concept. I agree to wait Fabrice's approval for any further releases!
Also having always-format as option is very good idea.
In source is implemented a workaround which adds <CR> to all <CR><LF> sequences in sector data - IMO this is related to very old MS-DOS versions and is not needed anymore...
writedsk2f.zip
(60.75 KiB) Downloaded 30 times
To build DOS executable I used cross DJGPP. The cross toolchain was build from zero very quickly with build-djgpp - great piece of software!

Post Reply

Who is online

Users browsing this forum: No registered users and 9 guests