Page 4 of 7

Re: Bug reports

Posted: Fri Aug 22, 2014 1:22 pm
by Jookie
atariancom wrote:I've had some fun, have been having problems partitioning sd card with latest hd drive version 9, I get can't write to boot and can't write to root. It gives me 3 partitions! That's a 4 meg, also tried with 8 meg and 2 meg.

It does a 128meg sd in compatible windows mod fine.

So is it hd driver or CE? So I tried hd driver on ultrasatan and that partitioned fine. So I can get around the problem, but would be nice to be able to do it within CE.

Tried it on a mega ste tos 2.06 and an ste under 1.62 & 2.06 same result.


Hello Steve,

could you please tell me the SD card size you used, and partition settings you used? (how many partitions, how big, what type)
I will try it with my HDDRIVER 9 and STE and will see if I can get the same result - that would help me to fix the issue.

Jookie

Re: Bug reports

Posted: Fri Aug 22, 2014 8:38 pm
by HuggyOne76
Jookie wrote:
HuggyOne76 wrote:Hardware bug... oh oh... The problem is the price to send you back the CosmosEx... ! My STE is unhappy... :?


Yeah :( I wished for software only bugs so they could be fixed remotely, but I guess nothing goes perfectly... So you don't have anyone around with a soldering iron? It's a quick fix - just one extra resistor needs to be added.

Or you could use a electrically conductive glue to glue the additional resistor there, using some tweezer to place the resistor there - maybe you could get that glue from some local store, or I see some available on eBay for ~2 Euro (from China, including postage costs). This way you would avoid the soldering, you just need a good grip with the tweezer.


I curse you Jookie !!! Ah ah ah !!! :lol:
So... I found an easier issue to my problem (not very good on soldering and anybody to do this for me so...) : I've got more than one STE in my bag... I took my second STE and this time, not the "bad DMA chip" ! I tried and... that's it ! IKBD works perfectly.
Nevertheless... Is there a "risk" for my Atari STE or the CosmosEx device to let this hardware bug or not ?

Re: Bug reports

Posted: Fri Aug 22, 2014 9:07 pm
by atariancom
Jookie wrote:
atariancom wrote:I've had some fun, have been having problems partitioning sd card with latest hd drive version 9, I get can't write to boot and can't write to root. It gives me 3 partitions! That's a 4 meg, also tried with 8 meg and 2 meg.

It does a 128meg sd in compatible windows mod fine.

So is it hd driver or CE? So I tried hd driver on ultrasatan and that partitioned fine. So I can get around the problem, but would be nice to be able to do it within CE.

Tried it on a mega ste tos 2.06 and an ste under 1.62 & 2.06 same result.


Hello Steve,

could you please tell me the SD card size you used, and partition settings you used? (how many partitions, how big, what type)
I will try it with my HDDRIVER 9 and STE and will see if I can get the same result - that would help me to fix the issue.

Jookie



I first tried with 8 gig sd card. Had a good old play with sizes. Split into 16 at first, then 8 all partition sizes were less than 512meg. Then tried a 4 gig card split into 8 and 16, I was trying alsorts. Think partition types were bgm, only needed then for data so didn't need to be gem.

Just had a thought, wonder if machine speed could be a factor as mega ste is at 16mhz and ste is 8mhz??

Re: Bug reports

Posted: Tue Aug 26, 2014 5:41 am
by Jookie
HuggyOne76 wrote:Nevertheless... Is there a "risk" for my Atari STE or the CosmosEx device to let this hardware bug or not ?


No, there is no risk for CosmosEx or your STE, it's just won't work properly...

atariancom wrote:I first tried with 8 gig sd card. Had a good old play with sizes. Split into 16 at first, then 8 all partition sizes were less than 512meg. Then tried a 4 gig card split into 8 and 16, I was trying alsorts. Think partition types were bgm, only needed then for data so didn't need to be gem.

Just had a thought, wonder if machine speed could be a factor as mega ste is at 16mhz and ste is 8mhz??


Steve, this issue has now been fixed, tested with HDDRIVER and with ICD Pro, see this:
http://www.atari-forum.com/viewtopic.php?f=103&t=26842#p257286
Could you, please, update and verify if it helped?

Re: Bug reports

Posted: Tue Aug 26, 2014 7:02 pm
by attle
Issue 1: Not sure if this is already reported. I have to go into the settings and re-save my DNS setting every time I want to use the update feature. Usually this is from a cold boot. The other settings such as static IP, gateway etc. are "remembered" by CE. But the DNS field is empty.

Issue 2: I want to use Musicmon: http://www.pouet.net/prod.php?which=18929
But when I start it from SD card or network drive, the graphics are very corrupt, just some vertical bars and numbers are visible. Not sure if this is an issue with CE at all, but can someone else try it? :)
Edit: Just copied Musicmon to a floppy, and it works from there so maybe it's just poorly adapted to run from hard drives.

Re: Bug reports

Posted: Wed Aug 27, 2014 6:18 am
by Jookie
attle wrote:Issue 2: I want to use Musicmon: http://www.pouet.net/prod.php?which=18929
But when I start it from SD card or network drive, the graphics are very corrupt, just some vertical bars and numbers are visible. Not sure if this is an issue with CE at all, but can someone else try it? :)
Edit: Just copied Musicmon to a floppy, and it works from there so maybe it's just poorly adapted to run from hard drives.


One thing you could try is to run it from SD card (inserted in the SD card slot, not through USB reader), disable the translated drive so you would have only SD card as the only ACSI ID assigned, then boot from the SD card (ICD Pro or HDDRIVER) and then see if it behaves the same. The point of this is to have the CE_DD (translated disk driver) not loaded as it might alter some GEMDOS behavior - if it would work like this, then the issue would be probably in CE_DD.

Re: Bug reports

Posted: Wed Aug 27, 2014 10:21 am
by attle
Jookie wrote:One thing you could try is to run it from SD card (inserted in the SD card slot, not through USB reader), disable the translated drive so you would have only SD card as the only ACSI ID assigned, then boot from the SD card (ICD Pro or HDDRIVER) and then see if it behaves the same. The point of this is to have the CE_DD (translated disk driver) not loaded as it might alter some GEMDOS behavior - if it would work like this, then the issue would be probably in CE_DD.


Yup! That works. Bug confirmed, I guess? :cheers:

Re: Bug reports

Posted: Mon Sep 01, 2014 3:17 pm
by wietze
I did some testing with regards to floppydisk swapping:

- On the actual hardware, with a real floppydrive, I tested 3 disks;
1). Insered disk, opened A:\, viewed contents closed it again
2). Swap disk, opened A:\, viewed contents, repeat

I found that the Atari STE would correctly display the contents of the disks, meaning, everytime I swapped a disk, the contents visible in A:\ would reflect the disk currently in the floppydisk.

With the CosmosEx, I had 3 images loaded (making sure taht these would not have the similar bootsector like the automation disks).
When opening A:\, closing it, and swapping the disk image by pressing the on-hardware button, and subsequently opening the diskdrive again, the contents of the drive would still show the contents of the first disk.

This leads me to believe that this is still a cosmosex bug. Can anyone happen to reproduce this?

Re: Bug reports

Posted: Sat Sep 13, 2014 10:40 am
by wietze
One thing I found; a situation where an application loaded from the TRANS drive crashes (2 bombs), but the same application loaded from SDCARD doesnt.

When running UTILITY.PRG from the cracked Chaos Strikes Back Harddisk version, it DOES run from SDCARD. But crahses when ran from the TRANS drive.

There must be some internal differences as to how the files are handled.

http://dmweb.free.fr/files/CSB-Game-AtariST.rar

Can anyone reproduce this bug?

Re: Bug reports

Posted: Tue Sep 16, 2014 9:27 pm
by wietze
Latest appl upgrade (16-09) does not fix certain crashes when loading programs/games from translated drive (that do in turn run properly from sdcard).

For example, Pirates! (http://dbug.kicks-ass.net/patches/2009/pirates.zip) runs from sdcard, but crashes to desktop after the opening screen when ran from translated (network) drive.

Hope this report is useful Jook :)

Regards,
Wietze

Re: Bug reports

Posted: Wed Sep 17, 2014 5:51 am
by Jookie
wietze wrote:Latest appl upgrade (16-09) does not fix certain crashes when loading programs/games from translated drive (that do in turn run properly from sdcard).


...and it even shouldn't - there was nothing related to crashing of apps - there's some problem in Pexec() function, this hasn't been touched for the last few updates. I will look at this in the following days.

Re: Bug reports

Posted: Wed Sep 17, 2014 6:54 am
by DrCoolZic
I need more test but I found a strange behavior on translated test.
In one of my programs I open a file selector for selecting a directory but on the network drive I see no directories. Strange as this seems to work from the desktop

Re: Bug reports

Posted: Wed Sep 17, 2014 7:15 am
by wietze
Jookie wrote:
wietze wrote:Latest appl upgrade (16-09) does not fix certain crashes when loading programs/games from translated drive (that do in turn run properly from sdcard).


...and it even shouldn't - there was nothing related to crashing of apps - there's some problem in Pexec() function, this hasn't been touched for the last few updates. I will look at this in the following days.


Than I misunderstood one of the changes. Apologies.

Re: Bug reports

Posted: Wed Sep 17, 2014 7:19 am
by Jookie
wietze wrote:Than I misunderstood one of the changes. Apologies.


No problem ;) I just wanted to let you know, that that shouldn't expect it to be fixed in that version...

Re: Bug reports

Posted: Wed Sep 17, 2014 8:01 am
by attle
wietze wrote:Latest appl upgrade (16-09) does not fix certain crashes when loading programs/games from translated drive (that do in turn run properly from sdcard).

For example, Pirates! (http://dbug.kicks-ass.net/patches/2009/pirates.zip) runs from sdcard, but crashes to desktop after the opening screen when ran from translated (network) drive.

Hope this report is useful Jook :)

Regards,
Wietze


Yep, most HDD loaders except those from Klaz don't work for me either.
Can someone else try Musicmon ( http://www.pouet.net/prod.php?which=18929 ) from a translated drive? It just displays a white screen with some corrupt graphics.

Re: Bug reports

Posted: Sun Sep 21, 2014 11:57 am
by widower2008
widower2008 wrote:
widower2008 wrote:
Ok now have my CosmosEx powered and connected using the external power. To be able to see the device I have to connect it to the hard drive ASCI port on the back of my Mega ST 2, Ethernet and not using the IKDB injector as with this connected the original keyboard seems to work but the mouse gets stuck in the top left corner of the screen!

I have tried to set up the shared drive and an SD card but so far I am not having much luck. I have used the CE_CONF.PRG to setup as follows
ACSI config tool
id 0 = trans
id 1 = sd
id 3 to 7 = raw - not sure why but doesn't seem to matter for what I am doing so far!

Translated disk
First translated as G
Shared drive as P
Config Drive as O

Shared drive is enabled using cifs
server IP is valid
share is entered as Atarishared
Valid username and password defined

(The share is on a Netgear NAS drive and has been tested with the user id and password from a windows box)
Floppy config is enabled as drive 1 (Note my old diamond button drive doesn't rotate but the stepper motor is fine!)
I can open the Drive O no problem, when I add drive P it shows as an empty drive which I then copied a file to and that appears to be on the Raspberry Pi SD card not the SD in the external SD slot......
Not sure where I am going wrong but hoping for more help if possible as you guys seem to know stack loads!
Hope to add a PC floppy with the cable fix mentioned elsewhere on here if I can find a 34 pin male and female idc plus a spare bit of 34 way cable - might cut it off a spare PC cable but then need the male end so I don't need to damage the Atari original!



Update - OK cann now connect via Raspberry Pi and via CosmosEx Raspberry device to Netgear share but via nfs using the following (ip addresses permitted for read write access)

pi@raspberrypi ~ $ sudo mount -v -t nfs -o nolock 192.168.1.84:/Atarishared /mnt/shared
mount.nfs: timeout set for Tue Aug 19 16:34:57 2014
mount.nfs: trying text-based options 'nolock,vers=4,addr=192.168.1.84,clientaddr=192.168.1.107'
mount.nfs: mount(2): No such file or directory
mount.nfs: trying text-based options 'nolock,addr=192.168.1.84'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.1.84 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.1.84 prog 100005 vers 3 prot UDP port 48770
pi@raspberrypi ~ $ ls /mnt/shared
ALL_SWR COPYACC CREDISK.zip drimg-0.86.tar.gz EMPTYFLO.zip FLOFOR.zip FO98.zip hddriver90_demo.zip icdp655a.zip SupHD.rar tos104uk.zip tos162uk.zip
ALL_SWR.zip COPYACC.zip DISKIMAG.zip drimg13.zip FdInstall.zip FloImg1.zip hddriver90_demo icdp655a SELTOS.zip tos102uk.zip tos106uk.zip TRACCPR.zip
pi@raspberrypi ~ $

Note - this also works from CosmosEx - just need to get the CosmosEx and Atari Mega ST2 talking again now!! :roll:


Fantastic! :cheers:

Have now managed to rebuild the Pi SD card and with the new software downloaded from the WEB and have a connected CosmosEx, with access to my shared drive using NFS - just using ACSI 0 for Translated and 1 for SD card. So now with an external floppy drive casing on the way I may be able to get it all working sooner rather than later!

Re: Bug reports

Posted: Wed Sep 24, 2014 3:59 pm
by Kirkman
SHARED DRIVE PROBLEMS
Jookie, here's a little bit more detail on the hard drive problems I mentioned in the releases thread. Sorry for posting there instead of here.

For reference:
  • CosmosEx updated to most recent software
  • Atari MegaSTe, 4 megs, TOS 2.06
  • Shared directory is on a Mac, shared using NFS
  • Using SD card in CosmosEx as a hard drive. Formatted with ICD Pro

The problems:
  • Copying multiple items
    • I select several items on my shared drive, then drag them to another window (SD card, floppy, etc).
    • After copy is complete, all the copied files have same file length as the first file in the selection
    • Inspecting the files, indeed, they *are* all copies of the first file, except with different file names.
    • (Copying items one at a time works as expected)
  • Copying folders
    • Dragging any folder from my shared drive to any other drive (floppy or HD) causes TOS to pop up an "Illegal operation!" error message
  • Disappearing files on N drive
    • N drive is shared drive, O drive is CosmosEx utilities drive
    • Open both drives; each window show list of several files; leave windows open
    • Run CE_CONF.PRG in O drive; quit back to Desktop
    • O drive window still lists all correct files; N drive window now says "3335 byes used in 1 item" and lists "CE_CONF.PRG" as that item, even though this program doesn't exist on N drive.
    • Closing N window and re-opening it causes all correct files to appear again.
    • Same problem happens with any program I run from the O drive (CE_MOUNT, etc)

Re: Bug reports

Posted: Wed Sep 24, 2014 9:48 pm
by Jookie
Kirkman wrote:SHARED DRIVE PROBLEMS
Jookie, here's a little bit more detail on the hard drive problems I mentioned in the releases thread. Sorry for posting there instead of here.


Damn... I wonder if it's caused by that TOS version, by the Mega STE caches, or by something different. Thanks for the report, I will take a look at that.

Re: Bug reports

Posted: Mon Oct 06, 2014 10:25 pm
by Jookie
@Kirkman
There's a new update for the Main App which fixes the 'Disappearing files on N drive' (actually on all translated drives). After this fix I wasn't able to reproduce the other problems you reported (I didn't try that before the fix), and from the description they might have been caused by the same thing, so please update your device and see if you still have any of those issues, or if they are all gone.

Re: Bug reports

Posted: Tue Oct 07, 2014 10:11 am
by DrCoolZic
I has same problem with my system and TOS 2.06 and I confirm it is now fixed
However if booting from config drive still getting 4 bombs :(

Re: Bug reports

Posted: Tue Oct 07, 2014 10:25 am
by Jookie
DrCoolZic wrote:I has same problem with my system and TOS 2.06 and I confirm it is now fixed
However if booting from config drive still getting 4 bombs :(


Damn... On my MegaSTE with TOS 2.05 it boots without those bombs all the time... I wonder what's causing that - I have to investigate this one further.

Re: Bug reports

Posted: Tue Oct 07, 2014 11:31 am
by Jookie
I've tested that with Steem and TOS 2.06 and there wasn't a crash, but as there is no real device connected and thus all the ACSI commands to device fail, it doesn't behave the same as with the real device and real ST, so this was useless. It would be great to have easily changeable TOS from 1.00 to 2.06, but the current solutions don't seem to be that good, and I'm also not sure if all those versions would work on various ST machines.

I remember one more thing... Setting the boot drive to config drive (O:) when no other drive is available (no SD card / no drive C:) is there after loading the CE_DD so TOS could load DESKTOP.INF / NEWDESK.INF and thus show config drive (O:) icon on the desktop. This feature is disabled on TT, because on TT setting the boot drive causes the 4 bombs after loading CE_DD - this was found by ggn / kua. Maybe there's something similar with the TOS 2.06...

You can test if the NEWDESK.INF is causing issues on the bootdrive like this:
- get your setup in a state, where booting of CE_DD will cause 4 bombs
- then log in through SSH, and rename or delete file /ce/app/configdrive/NEWDESK.INF and DESKTOP.INF
- then try to boot again and see if the 4 bombs still appear

Re: Bug reports

Posted: Tue Oct 07, 2014 12:25 pm
by DrCoolZic
Seems to be related to some state variable.
Sometime it works sometimes not
Work environment is CosmosEx mounted inside Atari. So no other choice than start Atari at same times as CosmosEx
config id0=sd id1=tran USB as TRAN

OK took me sometimes to find out the faulty sequence. Because I though the problem was gone?
Here are the tests

Powerup. System displays testing RAM .... wait until ACSI LED blink and hit ESC. System loads CE_DD after drive O mounted message, clear screen and takes abnormally long time to display destop.
Push reset button. same as above take long time but display desktop
no bombs?

Put the SD card with HDD and CE_DD in AUTO: load HDD then loads CE_DD and desktop comes quickly
reset => still works OK

Now keep power on but remove SD card.
reset system => CE_DD loads and after drive O mounted message I get 4 bombs
reset => load CE_DD and 4 bombs

So it seems that in some cases system is able to "recover" after taking long time and in some cases it crashes?
only difference is "history" of what happened before so must be problem with some state variables as "reset button" does not reset state variables.

Hope this help

Re: Bug reports

Posted: Tue Oct 07, 2014 12:57 pm
by Jookie
With the bombs on the picture shown after 'Setting boot drive to O' it looks just like the issue with TT and TOS 3.0x - that setting of boot drive is what is disabled there.

Re: Bug reports

Posted: Tue Oct 07, 2014 5:14 pm
by DrCoolZic
Jookie wrote:With the bombs on the picture shown after 'Setting boot drive to O' it looks just like the issue with TT and TOS 3.0x - that setting of boot drive is what is disabled there.

???
my machine is plain Atari STe with TOS 2.06