Floppy Emulation issues

News, questions and bugs reports about CosmosEx by Jookie. Now we have a Raspberry Pi in our machines!

Moderators: Jookie, Moderator Team

User avatar
Jookie
Hardware Guru
Hardware Guru
Posts: 1245
Joined: Wed Feb 04, 2004 6:54 pm
Location: Kosice, Slovakia
Contact:

Re: Floppy Emulation issues

Postby Jookie » Tue Jan 05, 2016 5:19 pm

Damn, that's pretty bad... I will work on that, hopefully it will be something small.

User avatar
Mr Nours
Captain Atari
Captain Atari
Posts: 203
Joined: Mon Jun 17, 2002 11:10 am
Location: Montpellier, France
Contact:

Re: Floppy Emulation issues

Postby Mr Nours » Tue Jan 05, 2016 8:12 pm

Jookie,

I had plugged an external FDD as secondary drive B: and put TST_FDD.PRG and CE_DD.PRG on a DD floppy.
I had loaded floppy images on the CE emulated drive A: via the web interface.
unplug acsi cable, reset STE
launch ST_FDD.PRG from B:

Results :

TEST disk = All tests succesful - Checksum : F040 ( correct )
A_400.ST = All tests succesful - Checksum : 9FEF ( correct )

if i plug the ACSI cable back, launch CE_DD.PRG, mount O:, ran TST_FDD.PRG and bam! all the tests failed for both images ( lots of DDDD ).

So i think this is a proof that CE_DD.PRG somewhat kills the floppy emulation or the floppy r/w subroutine...and that the firmware works fine without CE_DD.PRG on STE.

Please tell me if you need more testing. Is there a debug mode on the CE that may show more logs via the pi shell ?

Nrs.
______
Fuzion, the best french Atari CD crew ->The Fuzion Shrine!
ST emulation and more ->Emulation Atari ST(fr)!

User avatar
Jookie
Hardware Guru
Hardware Guru
Posts: 1245
Joined: Wed Feb 04, 2004 6:54 pm
Location: Kosice, Slovakia
Contact:

Re: Floppy Emulation issues

Postby Jookie » Wed Jan 06, 2016 12:01 am

Mr Nours wrote:So i think this is a proof that CE_DD.PRG somewhat kills the floppy emulation or the floppy r/w subroutine...and that the firmware works fine without CE_DD.PRG on STE.


Yes, good work there, Mr Nours :) I got similar results from Wietze, who reported this by e-mail.

I couldn't reproduce it on my STFM. I couldn't reproduce it on the STE which is use mostly (with HD floppy mod). So I pulled out another STE (without HD floppy mod) that I have and... I can finally reproduce it! (OK without CEDD, fails terribly with CEDD).

While testing this I also have found out the previously mentioned thing - it doesn't work at all on machines with HD floppy mod. The cause for that is that the floppy pin 2, which is used for HD/DD detection, is pulled up to 5V (logical 1), which is wrong and should be pulled to GND instead, so I had to remove one pull up resistor to make it work there. The better option would be to put also a pull down resistor now to not let the pin 2 float.

People who do have this HD floppy mod might need to remove that resistor, or even cut one trace on PCB of CosmosEx, or disable that floppy mod (e.g. by a switch). I will create a page for that later.

Mr Nours wrote:Please tell me if you need more testing.


No, thank you, now that I can reproduce it, I will probably be able to debug and fix it without further help.

Mr Nours wrote:Is there a debug mode on the CE that may show more logs via the pi shell ?


1) log in the linux
2) terminate the main app and watchdog script by running: /ce/ce_stop.sh
3) run the main app with ll3 param - that means debug logs, like this: /ce/app/cosmosex ll3
4) a log file is located at /var/log/ce.log . On standard log level it doesn't contain much info, but on log level 3 (ll3, debug level) it can grow a log if you run it for a while or execute many stuff over ACSI, so don't use it too often ;)

User avatar
Mr Nours
Captain Atari
Captain Atari
Posts: 203
Joined: Mon Jun 17, 2002 11:10 am
Location: Montpellier, France
Contact:

Re: Floppy Emulation issues

Postby Mr Nours » Wed Jan 06, 2016 10:08 am

Ok, glad to see you could reproduce the bug.
Hope it will not be too much work for you to fix this one.

Thanks for the log-level tip, i will play with that...

Cheers,

Nrs.
______

Fuzion, the best french Atari CD crew ->The Fuzion Shrine!

ST emulation and more ->Emulation Atari ST(fr)!

User avatar
Jookie
Hardware Guru
Hardware Guru
Posts: 1245
Joined: Wed Feb 04, 2004 6:54 pm
Location: Kosice, Slovakia
Contact:

Re: Floppy Emulation issues

Postby Jookie » Thu Jan 07, 2016 11:58 pm

There is a new version of Hans (hard drive chip) firmware, which should fix a part / the whole issue.

Hans FW did use some Xilinx feature to get the status of ACSI bus - for special cases when recovery might be needed, but the Xilinx feature caused that the INT line of ACSI port stayed low after every command to CosmosEx (but not after command to SD card or other ACSI IDs which were not assigned to CosmosEx). I removed the usage of this feature (it's not needed anyway, the recovery will be done in a different way), now the INT line is nicely back to normal after communication with CosmosEx, and thus it shouldn't interfere with floppy communication (HDD and FDD are sharing some signals).

Please update your FW, test it, and report if this got better. This should correct the situation where you had many errors.

There was a reported issue with some game which didn't work when loaded through emulated floppy interface, this issue might be something different. Please try that one, too, and report how that one goes, too.

User avatar
Mr Nours
Captain Atari
Captain Atari
Posts: 203
Joined: Mon Jun 17, 2002 11:10 am
Location: Montpellier, France
Contact:

Re: Floppy Emulation issues

Postby Mr Nours » Fri Jan 08, 2016 7:32 pm

Thanks you, i updated the firmware to the latest version you provide and ran some tests.
This is way better!

I ran the tests on my STE ( 4Mo, TOS 1.62 FR )
Cosmosex plugged as FDD A:
Boot on Emulated Hard disk as ACSI 0, CE_DD Loaded.

Results :


Test with the fdd_test.st image disk loaded on slot 1 ( A: ) :
All tests succesful ( R/N/S ) - checksum correct ( F040 )
Test with the automation 400 image disk ( A_400.ST ) loaded on slot 1 ( A: ):
All tests succesful ( A/D/E ) - checksum correct ( 9FEF )
Test with fuzion 87 CD ( fuzion_87.st ) loaded on slot 1 ( A: ):
All tests succesful ( A/D/E ) - checksum correct ( CD3F )

Unfortunately I always had screen data corruption on magic pocket with the fuzion cd 87 even if it has been checked with a correct checksum and the Autoboot bug ( won't boot correctly on A: if this is not after a hard reset ) as described in another post is also here.

A point for Jookie! :cheers:

Oh, and I had some of those lines in the ce log :

Code: Select all

00015221   00000155   (2016-01-06 10:10:07)   Side / Track out of range, returning empty track
00017971   00002750   (2016-01-08 18:59:53)   Side / Track out of range, returning empty track


What are they related to?

Cheers,

Nrs.

fuzcd087.st
You do not have the required permissions to view the files attached to this post.
Last edited by Mr Nours on Fri Jan 08, 2016 8:37 pm, edited 1 time in total.
______

Fuzion, the best french Atari CD crew ->The Fuzion Shrine!

ST emulation and more ->Emulation Atari ST(fr)!

User avatar
Jookie
Hardware Guru
Hardware Guru
Posts: 1245
Joined: Wed Feb 04, 2004 6:54 pm
Location: Kosice, Slovakia
Contact:

Re: Floppy Emulation issues

Postby Jookie » Fri Jan 08, 2016 8:35 pm

Mr Nours wrote:This is way better!
A point for Jookie! :cheers:

Great ;) Finally some improvement.

Mr Nours wrote:Unfortunately I always had screen data corruption on magic pocket with the fuzion cd 87


This might be then related to wrong geometry detected - if it's not standard 80 / 9 /2 floppy... I will have to check that.

Mr Nours wrote:and the Autoboot bug ( won't boot correctly on A: if this is not after a hard reset ) as described in another post is also here.


I will have to check that one too, this is weird...

Mr Nours wrote:Side / Track out of range, returning empty track
What are they related to?


This happens when the Franz chip requests a track / side number, which seems to be out of range (e.g. trying to read track 82 on a floppy which has only 80 tracks). This might be either due to bad detecting step / side signals on floppy interface, or due to badly loaded image in Main App under linux.

User avatar
Jookie
Hardware Guru
Hardware Guru
Posts: 1245
Joined: Wed Feb 04, 2004 6:54 pm
Location: Kosice, Slovakia
Contact:

Re: Floppy Emulation issues

Postby Jookie » Fri Jan 08, 2016 9:15 pm

OK, FloImg from Ppera says, that the Fuzcd87.st has geometry: 82 / 10 / 2.
The CE Main App log shows the following: ST Image params - 82 tracks, 2 sides, 10 sectors per track
...so at least it knows it's the right geometry. There might still be some issue there, but it's a good start ;)

The ce_tstfd.prg currently tests reads within the range of 80 / 9 / 2, so it's not accessing all the tracks, that's why it might show the same crc as under Steem, but CE still might have issues reading the higher tracks / last sector on track. I will have to go through that and see what I will come up with.

User avatar
Jookie
Hardware Guru
Hardware Guru
Posts: 1245
Joined: Wed Feb 04, 2004 6:54 pm
Location: Kosice, Slovakia
Contact:

Re: Floppy Emulation issues

Postby Jookie » Fri Jan 08, 2016 11:39 pm

I have altered the floppy test to guess the geometry and try to access everything, that would be up to 82 / 10 / 2, and I got the same checksum from Steem and from real STE, so it seems that it's able to access the whole geometry. I didn't try the game as I don't have a color TV connected, only mono LCD and that wouldn't work. So my guess now is:
- I got a couple (5) lazy reads (not on the 1st try, but on the retry) out of 1640 sectors. If the game doesn't use the Floprd TOS function which does the retries, but instead handles the floppy directly, without the retry it might fail
- the floppy test reads one sector at the time, maybe I should add a test for reading the whole track at the time and see if the results are the same or different

Ideally there would be no lazy reads, and the log shouldn't contain any 'Side / Track out of range, returning empty track' messages when loading that game. I could have a look at that...

Does anybody else have an idea what to test and how with this game?

User avatar
Mr Nours
Captain Atari
Captain Atari
Posts: 203
Joined: Mon Jun 17, 2002 11:10 am
Location: Montpellier, France
Contact:

Re: Floppy Emulation issues

Postby Mr Nours » Sat Jan 09, 2016 12:02 pm

I had modified the fuzion image to be 80/9/2. ( attached )
I removed the second game for that ( Only valid choice is now 1 - Magic Pocket ).

If you run this image with Steem then choose "1", you'll got the same screen corruption than with the orginal image disk on CE.
Seems that something in the code run by the menu disk is related to the disk geometry...i'm a bit disapointed :shrug:
I was thinking that the 80/9/2 image should run fine under Steem and CE but it get screen corruption on both.
The original image works fine on Steem or Hatari, but get image corruption on CE.

What's the point?

Nrs.
You do not have the required permissions to view the files attached to this post.
______

Fuzion, the best french Atari CD crew ->The Fuzion Shrine!

ST emulation and more ->Emulation Atari ST(fr)!

User avatar
Jookie
Hardware Guru
Hardware Guru
Posts: 1245
Joined: Wed Feb 04, 2004 6:54 pm
Location: Kosice, Slovakia
Contact:

Re: Floppy Emulation issues

Postby Jookie » Sat Jan 09, 2016 11:22 pm

Mr Nours wrote:I had modified the fuzion image to be 80/9/2. ( attached )
I removed the second game for that ( Only valid choice is now 1 - Magic Pocket ).

If you run this image with Steem then choose "1", you'll got the same screen corruption than with the orginal image disk on CE.
Seems that something in the code run by the menu disk is related to the disk geometry...i'm a bit disapointed :shrug:


That's a weird thing... But at the same time it's also a sign that it's doing something weird. It would help me to debug the issue if someone would know what's happening there.

I'm talking to tIn over e-mail, he had a similar issues with his floppy loader, which doesn't use TOS function Floprd() for accessing the floppy disk but it's all done by him, so maybe with his code example we might be able to trace the issue somehow... It seems that the TOS function for floppy access might be more robust that the ones who were made be demo and game developers ;) (or at least in some cases).

Mr Nours wrote:The original image works fine on Steem or Hatari, but get image corruption on CE.


Currently I can only guess what's wrong, and my guess is that some lazy read (not on the first floppy rotation, but on some of the next one) might cause that, because from the last test I made previous night it seems that I can nicely access all the sectors of that 82 / 10 / 2 floppy, even the checksum from CE and Steem are the same, but I'm using that TOS function for reading that floppy.

I need to see the issue from the other side - from the side of the problematic loader(s), that's why I hope that with tIn's help I might have better test, which will report more about the loading issue from the ST side (e.g. loading takes too long? or don't they check the floppy CRC? or whatever). My current view of the issue from the point of the emulated drive seems not to be enough. So let's see how this will continue (with the possibly newer and better test).

User avatar
Jookie
Hardware Guru
Hardware Guru
Posts: 1245
Joined: Wed Feb 04, 2004 6:54 pm
Location: Kosice, Slovakia
Contact:

Re: Floppy Emulation issues

Postby Jookie » Sun Jan 17, 2016 7:49 am

mr Nours, please try the latest update (Franz FW changed) and see if you can now load the problematic Fusecd image.

User avatar
Mr Nours
Captain Atari
Captain Atari
Posts: 203
Joined: Mon Jun 17, 2002 11:10 am
Location: Montpellier, France
Contact:

Re: Floppy Emulation issues

Postby Mr Nours » Sun Jan 17, 2016 1:45 pm

You did it Jooking !
Image
Two thumbs up!

I had tried to play magic pockets and it just depack and runs fine. No more screen corruption, even with acsi cable plugged.
Just loaded the floppy img via web interface then reboot, hammering "A" on keyboard, and played.

So.. What was the story of this bug?

If you please so i will try some other images disk and compare how they works with steem/hatari and cosmosex and report eventual problems.

Thanks!

Nrs.
______

Fuzion, the best french Atari CD crew ->The Fuzion Shrine!

ST emulation and more ->Emulation Atari ST(fr)!

User avatar
Jookie
Hardware Guru
Hardware Guru
Posts: 1245
Joined: Wed Feb 04, 2004 6:54 pm
Location: Kosice, Slovakia
Contact:

Re: Floppy Emulation issues

Postby Jookie » Mon Jan 18, 2016 11:26 am

Mr Nours wrote:You did it Jooking !
Image
Two thumbs up!


LOL, nice, thanks ;)

Mr Nours wrote:So.. What was the story of this bug?


I was testing the floppy reading and seeking with Floprd() function from TOS, which worked nicely, but it apparently does have some retries implemented, so the issue wasn't visible with that. Then I've took some code for FDC for reading floppy sectors (credit goes to ggn for providing me with the link to the FDC code), I've modified the floppy test and it showed many errors (which aren't visible when using Floprd()).

The FDC routine is silly, it doesn't do any retries, it doesn't even check the FDC status register to see if the sector was well read or if it was read with errors, so I guess any game or demo that does it this silly way might have had suffered from this issue.

The problem was occurring when the ST wants to seek and read a sector, and it happened around 1% of the time (e.g. that means 14 sectors out of whole 1440 sectors). When the new sector data is being loaded into Franz, the old one was still streamed from Franz to ST, slowly being rewritten by the new sector data, which in those 1% of cases resulted in CRC error when reading that sector (because it was still not fully loaded in Franz). This was fine with TOS and Floprd() because it did a retry, and the 2nd read was just fine (the data was already loaded in Franz), but if you used the silly FDC routine which failed sometimes on the 1st attempt, you ended with faulty data...

So the fix was just turning off the output stream when the new stream is being loaded, and then correctly positioning the pointer in the new stream (e.g. when the floppy is in half of the media rotation, position the stream pointer in the half).

Mr Nours wrote:If you please so i will try some other images disk and compare how they works with steem/hatari and cosmosex and report eventual problems.


Yes, if you can find a problematic floppy image, which works just fine with Steem / Hatari, but doesn't work with CosmosEx, tell me and I will try to fix it. I guess that there still might be some issues with MSA images, as they are more complicated than ST images, and I guess different imaging tools might have had produced some different MSA images...


Social Media

     

Return to “CosmosEx”

Who is online

Users browsing this forum: No registered users and 1 guest