Strange U1MB issue

[gargoyle]

@Gargoyle: can you update all three firmware components (main BIOS version should be 1.25, PBI BIOS 1.85) and see if the situation changes?

 

http://atari8.co.uk/wp-content/uploads/2016/12/Ultimate1MB_Firmware_Update_071216.zip

 

Will do, I can see where the the Main BIOS version is shown, but where in the Ultimate Setup i can see the PBI Bios version? Looks like I currently have the Ultimate BIOS version 1.20 (release) package flashed and I still have the error.

Edited April 20, 2017 by gargoyle

[gargoyle]

Great, latest full package (v1.25) works as intended. No speed issue either. Video will follow.

 

EDIT: I may have spoken too early. There still are some issues. I will update when I have more details.

 

EDIT: Ok, I reflashed with the latest v1.25 full ROM, rebooted with DOS 2.5 and was able to copy a file to D2: (MegaSpeedy Drive) in high-speed and without any problems, then within the same session i tried to delete the copied file from D2 and I've received a 138 error (device timeout), tried again and again and it is the same thing. I then rebooted with DOS 2.5 but with the PBI BIOS and high-speed OFF to see if i can delete the file and I was able to. I rebooted a 3rd time with PBI and high-speed back ON, this time i get the 138 error when i attempt to copy to D2:

I am totally lost now!.

 

Will upload a video soon....

Edited April 20, 2017 by gargoyle

[gargoyle]

And the video, note that this only shows the 3rd and final test session, unfortunately i wasn't capturing the 1st session where everything seemed to work right after the flash:

 

https://youtu.be/10267igOH-s

Edited April 20, 2017 by gargoyle

[lemiel]

With ideal clocks, an NTSC computer sends bits at 1.7898MHz / 32 = 55,930 bits/second, or 5,930 bytes/second with back-to-back bytes. The firmware's bit and byte receive loops are 18 cycles and 180 cycles @ 1MHz respectively, for a max rate of 55,556 bits/second, too slow by 0.7%. That tiny deficit is enough for excess skew to occur within a data frame. In contrast, a PAL computer sends at 55,420 bits/second, which gives the drive just barely enough headway... in ideal circumstances.

 

Could it be the reason why (almost?) all USA originated, ie. NTSC compatible, 1050 speeders were designed to work with 52kbps?

[_The Doctor__]

 

Could it be the reason why (almost?) all USA originated, ie. NTSC compatible, 1050 speeders were designed to work with 52kbps?

for cheapness sake maybe, but again, firmware tweak or clock fix with firmware update would allow for proper operation, lowest common denominator of 52 isn't always the answer... quick and dirty is just that...

Edited April 20, 2017 by _The Doctor__

[Bikerbob]

Well for my contribution to the thread.

 

I did update to the latest firmware on the U1mb and that also put in Spartados 4.49b - I can format now.. without the issues I was having.. EXCEPT.. and this was something I forgot before, but I am sure this is a Spartados thing not a U1mb thing.. but someone can tell me.. its just kind of related because of what we are talking about.

 

When I format in Spartdos.. it sees the megaspeedy.. gives me the option right away of Ultraskew.. but I cannot format it.. or hispeed skew.. in ANY mode the megaspeedy upgrade offers.

 

I have Rana1000, Trak ATD2, IndusGT - ALL I can format in Ultraskew.. now.. its still really fast.. so I assume.. that what sparta is trying to do with the format.. the speedy is doing with hardware???? or why is it??

 

James

[_The Doctor__]

Sparta just sends the commands and by some extensions for the indus at one point, some code... this tells the drive to switch to it's high speed and then Sparta talks to it at that speed.... when SPARTA tells a Megaspeedy to go high speed... the speedy drive switched to it's flawed high speed timing per it's firmware and/or design... Sparta picks the speed and at NTSC the speedy will once again lose bits because of the timing... I do not fault SPARTA et al... I fault the Megaspeedy that needs it's timing fixed one way or another..

 

What you could try is using Sparta to cap the sio speed to one step slower index for that drive... this might fix a number of issues for normal operations. It however does not follow it will fix the formatter as last I knew it didn't work through that... and does things on it's own... an issue I might have made mention of at some point in the past.

Edited April 20, 2017 by _The Doctor__

[Bikerbob]

ahhhh.. got ya.. I way pretty sure thats the way peripherals on the atari worked, but I did not want to put my foot in my mouth.

 

So, back to the mega.. OK.. well I guess I wait until a revision can be done by Hias, and then i would need to pull the chip and reprogram it on my willem .. correct??

 

James

[_The Doctor__]

I would to be absolutely sure.

[Bikerbob]

Sorry, I lied, more testing tonight.. back on E1 mode of the Mega, and the format failed again.

 

James

[Kyle22]

Does anyone know if the mega supports the get speed index command ? ?

 

Edit: You can read what the drive says about highspeed, but you most likely can't set it.

Edited April 21, 2017 by Kyle22

[HiassofT]

I have Rana1000, Trak ATD2, IndusGT - ALL I can format in Ultraskew.. now.. its still really fast.. so I assume.. that what sparta is trying to do with the format.. the speedy is doing with hardware???? or why is it??

Simply ignore the skew setting/warnings in the SDX formatter, it's not needed for the Speedy, using normal skew is fine.

 

That option is only needed for a bunch of drives that don't automatically format with the correct skew and/or have no trackbuffer.

 

The Speedy determines the sector skew automatically when you insert a disk, adjust it's track reading/writing sequence to it and so, because of the track-buffer, the sector skew on the disk doesn't matter.

 

so long,

 

Hias

[HiassofT]

Does anyone know if the mega supports the get speed index command ? ?

Yes, and it'll answer with $09 - ~59kbit/sec

 

Here's the list of speedy commands (use google translate to have some fun

https://atariwiki.org/wiki/Wiki.jsp?page=Das%20SPEEDY-System#section-Das+SPEEDY-System-Teil7

 

so long,

 

Hias

[_The Doctor__]

Not to get all crazy here, but sector skew can matter when using more than one real drive and type..... one skew method will work at fairly decent speeds across almost all drive types while another can be super fast on a specific drive and make all others crawl..... interleave of sectors the factor... since I use standard drive, happy, us doubler, xf, I settled on a something that works well on sd disks across the range and then something for DD across that range..

a further seperate issue is using whatever drive that formats and writes that out a disk can be key... for whatever reason, it matters. I experimented and the disk can boot or not boot on a drive controller that has not been initialized depending on the formatting drive and it's initializing, boot sector etc..

A work around for density select on XF's was done for Sparta so XF's would boot disk no matter what (posted it on some thread on AA)

 

Ignoring skew because a drive can track buffer is not IMHO the way to go.... sure it gets you by... but speed across the range of drives not only matters in your own house but when you share to entire community and others have wide and varied equipment.

Edited April 21, 2017 by _The Doctor__

[HiassofT]

FYI: I think I managed to fix the highspeed SIO issues of the (Mega-)Speedy on NTSC. I posted a first set of ROMs for testing in the Mega Speedy thread here:

http://atariage.com/forums/topic/258141-megaspeedy-operations/?do=findComment&comment=3746817

 

so long,

 

Hias

[Bikerbob]

Not to get all crazy here, but sector skew can matter when using more than one real drive and type..... one skew method will work at fairly decent speeds across almost all drive types while another can be super fast on a specific drive and make all others crawl..... interleave of sectors the factor... since I use standard drive, happy, us doubler, xf, I settled on a something that works well on sd disks across the range and then something for DD across that range..

a further seperate issue is using whatever drive that formats and writes that out a disk can be key... for whatever reason, it matters. I experimented and the disk can boot or not boot on a drive controller that has not been initialized depending on the formatting drive and it's initializing, boot sector etc..

A work around for density select on XF's was done for Sparta so XF's would boot disk no matter what (posted it on some thread on AA)

 

Ignoring skew because a drive can track buffer is not IMHO the way to go.... sure it gets you by... but speed across the range of drives not only matters in your own house but when you share to entire community and others have wide and varied equipment.

 

So is this something that you can pass along? or something I have to experiment with? Ultra seems to work on all my drives but the megaspeedy. I do know what you mean about specific drives formatting etc.. the TRAK seems the least able to configure itself, where as the Rana and the Indus change and can read and adapt to whatever disk I put in.

 

As a hobby I was always a hardware guy - now as a retro hobby - I love have all the drives, makes me ohh ahh that I have one of each that i coveted back in the day.. I spend very little time playing games, I like to mod, repair, configure, etc,, everyones hobby is different right??

 

James

[_The Doctor__]

The megaspeedy is not going to work imho until the firmware/timing is repaired.... it is a transmission level problem.... an error in firmware/and/or electronic design and Hias will find a firmware fix / workaround given time and if possible. A actual electronic fix might be needed as a true fix.

 

edit : Hias is already posting possible fixes to the firmware and working on the problem!

 

playing with sector interleave is something to be done again.... it is kind of the lowest common denominator approach for the drives... the actual reasons for the format and boot init is something to look into again further. The code change to Sparta's boot sector was already done for 3.2 and is in the XF tools and files I uploaded long ago... you can recognize it.... it will say something like....

BOOT ERROR

BOOT ERROR

Boot error?

 

then it boots!

 

I will have to see if an atr carries the behavior of format and speed I refer too. since it may be more than just related to interleave but also a function of drive rpm's and interleave. remember XF and certain other drives are not at 288 but 300 rpm

Edited April 22, 2017 by _The Doctor__

[Bikerbob]

Thats a point .. because I have an XF551 and I know about the 300rpm on that one.. I have a TRAK AT-D2 which a lot of people said to me it was a 300rpm drive.. but I could not get it to work and read anything at 300rpm.. Working like a charm at 288rpm?? so .... I would assume for the 300rpm XF to be able to read the 288 other disks.. there has to be something more to it.

 

James