Jump to content

Photo

Strange U1MB issue


67 replies to this topic

#26 _The Doctor__ OFFLINE  

_The Doctor__

    River Patroller

  • 2,040 posts
  • Location:10-0-11-00:02

Posted Sun Apr 16, 2017 12:57 AM

but when any pbi device gives up it's control you would think the table should be cleared... it's possible the peripherals that are connected to the pbi device will no longer be there.... this could be an issue especially when dealing with multiple pbi devices on the bus


Edited by _The Doctor__, Sun Apr 16, 2017 12:58 AM.


#27 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 12,215 posts
  • Location:United Kingdom

Posted Sun Apr 16, 2017 4:31 AM

but when any pbi device gives up it's control you would think the table should be cleared... it's possible the peripherals that are connected to the pbi device will no longer be there.... this could be an issue especially when dealing with multiple pbi devices on the bus

 

Not sure what you mean here by "gives up its control". As I say, the user can configure two things: the polling order (i.e. the priority) of the PBI handlers (IIRC device ID 7 is polled first and device 0 last; correct me if it's the other way around), and - in the case of the U1MB PBI HSIO handler - whether the SIO on a given drive is performed by its PBI SIO driver. So one can - for example - by arranging the PBI device IDs on two adapters (say IDE Plus 2.0 and U1MB PBI), force IO on D1: to be handled by U1MB and IO on D2: to be handled by the IDE Plus SIO driver. If neither PBI BIOS handles IO on a given drive, it will be handed over to the stock OS SIO handler (or to the SDX LSIO vector if present, which has priority over the OS SIO).

 

Deactivating one or the other PBI handler inevitably involves a system reset (the trigger to entering into BIOS setup) and therefore an OS reset, and on an OS reset the PBI HSIO handler clears the HSIO speed table.



#28 Bikerbob OFFLINE  

Bikerbob

    Dragonstomper

  • 500 posts
  • Location:Mississauga ON Canada

Posted Mon Apr 17, 2017 6:50 AM

Enhanced Ultimate 1MB BIOS also have problems with high speed SIO especially when a MegaSpeedy upgrade is used. Write operations to the enhanced drive fail.  The problem does not exist with the hi-speed patch from HIAS so i presume the problem is with the BIOS implementation.


I just finished my install of a megaspeedy - I am encountering a similar if not same issue.

1 - I was not able to get into the FLASHER program of the MegaSpeedy, when attached to the U1mb machine. Ended up.. if I went back to STOCK OS not HI-Speed OS it would boot to the Flasher no issues.

2 - I have Sparta 4.48 in my sparta SLOT - from this DOS if I try and format - it will run the cycle but when trying to WRITE the directory table at the end it will not stop.. it goes on and on, I have to turn off the computer and the drive.
I have not been able to reproduce this in any other dos. HI-Speed SIO is off in the profile.. does 4.48 load its own HI-SPEED sio?

James

ps, I might try and produce some video on this. Re-reading, it would seem my issue is not the same, I have no way to run 4.48 from a non-U1mb computer so that I have no idea if its hardware or software, any suggestions on troubleshooting would be welcome.

Edited by Bikerbob, Mon Apr 17, 2017 7:00 AM.


#29 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 12,215 posts
  • Location:United Kingdom

Posted Mon Apr 17, 2017 7:57 AM

PBI HSIO if enabled will override SDX SIO driver, otherwise SDX SIO driver handles serial IO. Perhaps one happy day one of the independent parties I ask to verify U1MB HSIO Megaspeedy issues will actually be able to reproduce a problem. ;)

#30 Bikerbob OFFLINE  

Bikerbob

    Dragonstomper

  • 500 posts
  • Location:Mississauga ON Canada

Posted Mon Apr 17, 2017 8:55 AM

PBI HSIO if enabled will override SDX SIO driver, otherwise SDX SIO driver handles serial IO. Perhaps one happy day one of the independent parties I ask to verify U1MB HSIO Megaspeedy issues will actually be able to reproduce a problem. ;)

 

OK, so in my situation, I dont have the PBI on (have to read manual again on PBI stuff)  Hardware wise mine is this.

800xl with U1mb and UAV - no other mods

profile 1 - 1088mb stock XL rom (OR HI-Speed OS) basic

profile 2 - 1088mb stock or HI and basic and SpartaX

 

1 1050 drive with MegaSpeedy (stock roms)

1 sio2pc (have done tests with it in.. or out)

 

I know the MegaSpeedy has a Hispeed SIO built into it.. I can turn it on or off from the FLASHER

 

when using a stock 800xl I have no issues - though as I said, I am not able to run Sparta 4.48 as I dont have it in a CART form.

 

James



#31 HiassofT OFFLINE  

HiassofT

    Dragonstomper

  • 998 posts
  • Location:Salzburg, Austria

Posted Tue Apr 18, 2017 1:04 PM

2 - I have Sparta 4.48 in my sparta SLOT - from this DOS if I try and format - it will run the cycle but when trying to WRITE the directory table at the end it will not stop.. it goes on and on, I have to turn off the computer and the drive.
I have not been able to reproduce this in any other dos. HI-Speed SIO is off in the profile.. does 4.48 load its own HI-SPEED sio?

I was able to reproduce that issue. It looks like the SDX SIO driver (yes, SDX comes with it's own higspeed driver) doesn't work well on NTSC machines - on PAL all is fine.

I could reproduce with the following setup:
MegaSpeedy as only drive, D1:, configured to megaspeedy mode ("E1")
Stock NTSC 800XL
SDX run from TurboFreezer (SDX is identical to U1MB version)
Start format.com, choose drive 1 and then build directory (not need to format)

One workaround for this is to disable the SDX SIO driver via config.sys - then the SIO driver from the OS will be used.
DEVICE SIO /A
Best check if this also occurs with other drive modes on NTSC and then post a bug report in the SDX 4.48 thread.

I haven't tested yet with my highspeed code on NTSC, will do that another time.

so long,

Hias

Edited by HiassofT, Tue Apr 18, 2017 1:04 PM.


#32 HiassofT OFFLINE  

HiassofT

    Dragonstomper

  • 998 posts
  • Location:Salzburg, Austria

Posted Tue Apr 18, 2017 3:29 PM

I did some more tests with the MegaSpeedy and my highspeed code on NTSC systems and it looks like writing to a Speedy drive in highspeed on NTSC systems doesn't work too well.

Command frame is ACKed but data frame NAKed.
DS2_2017418222528.png
DS2_2017418222613.png
DS2_2017418222628.png

That could be a general bug in the speedy firmware, so not sure we can do much about that...

so long,

Hias

#33 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 12,215 posts
  • Location:United Kingdom

Posted Tue Apr 18, 2017 3:34 PM

Interesting. I wondered about PAL/NTSC differences but everyone who reported problems with the PBI code (all using NTSC systems, I think) claimed that your high speed OS worked fine on the same hardware...

#34 HiassofT OFFLINE  

HiassofT

    Dragonstomper

  • 998 posts
  • Location:Salzburg, Austria

Posted Tue Apr 18, 2017 4:42 PM

Interesting. I wondered about PAL/NTSC differences but everyone who reported problems with the PBI code (all using NTSC systems, I think) claimed that your high speed OS worked fine on the same hardware...

Well, it kind of works with my highspeed code, but only because the command is retried in standard speed. SIO sounds when writing to a Speedy on an NTSC system are really ugly - and slow.

Guess I'll need to do some more tests to find out what's happening there.

so long,

Hias

#35 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 12,215 posts
  • Location:United Kingdom

Posted Tue Apr 18, 2017 4:52 PM

It's great that we finally have some meaningful analysis. Thanks!

#36 HiassofT OFFLINE  

HiassofT

    Dragonstomper

  • 998 posts
  • Location:Salzburg, Austria

Posted Tue Apr 18, 2017 5:42 PM

Last tests for today:

Analog signal (SIO TxD from Atari to drive) looks fine:
DS2_201741903816.png

And when configuring the MegaSpeedy to happy mode writes are fine as well on NTSC.

So, as suspected before, most certainly an issue with the Speedy firmware.

so long,

Hias

#37 CharlieChaplin OFFLINE  

CharlieChaplin

    River Patroller

  • 2,411 posts

Posted Tue Apr 18, 2017 6:18 PM

Hmmm, I think many years ago (when Abbuc got the rights of Compyshop hardware and began reproducing and selling the mini-Speedy), Abbuc Floppydoc or GoodbyteXL wrote, that the mini-Speedy would not work with NTSC systems. When the Mega-Speedy turned up and was sold worldwide, I assumed that this issue had been solved. But now it is there again. Maybe a look into the Speedy source helps to find out what the guys at Compyshop did (wrong) back in the 80s. Attached you will find the Speedy ROM listing (maybe it helps)...

 

Note: Remarks in the listing are in german language (Compyshop was from Germany)...

 

Attached Files


Edited by CharlieChaplin, Tue Apr 18, 2017 6:25 PM.


#38 Bikerbob OFFLINE  

Bikerbob

    Dragonstomper

  • 500 posts
  • Location:Mississauga ON Canada

Posted Tue Apr 18, 2017 8:13 PM

So can the megaspeedy firmware be updated?

Is that done on a ROM by ROM basis? or does the device as a whole need an update?

I will help with testing for sure.. but cant help with the code.. I am hardware guy.. not code.


James

Edited by Bikerbob, Tue Apr 18, 2017 8:19 PM.


#39 phaeron ONLINE  

phaeron

    River Patroller

  • 2,142 posts
  • Location:USA

Posted Tue Apr 18, 2017 10:15 PM

I actually ran into this problem emulating the Speedy 1050 in Altirra. The firmware is not quite fast enough to keep up with an NTSC computer sending back-to-back bytes, and on data frames it keeps falling behind slightly with each successive byte until it eventually drops a bit.

 

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.

 

One possible (ugly) workaround would be to use the serial output complete IRQ instead of serial output ready, which would use two stop bits and slow down the transmission.



#40 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 12,215 posts
  • Location:United Kingdom

Posted Wed Apr 19, 2017 6:04 AM

Can't seem to find the original video showing the U1MB PBI BIOS/Megaspeedy issue (presumably got pulled), but it's a shame RWTEST wasn't tried before high speed transfers using Hias' OS were announced working. ;) Anyway: I'm open to any compromise/patch necessary to work around the problem.

#41 HiassofT OFFLINE  

HiassofT

    Dragonstomper

  • 998 posts
  • Location:Salzburg, Austria

Posted Wed Apr 19, 2017 9:49 AM

I actually ran into this problem emulating the Speedy 1050 in Altirra. The firmware is not quite fast enough to keep up with an NTSC computer sending back-to-back bytes, and on data frames it keeps falling behind slightly with each successive byte until it eventually drops a bit.
 
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.

Awesome, this is excellent information, thanks a lot!

I alredy suspected something like this. Best way to fix this IMO is to fix the Speedy receive code, so that it's quick enough and can properly sync on every start bit. The 1050 turbo code is better optimized, faster bit cycles, storing data during stop bit, doing checksum update of previous byte during the start bit of next byte and can serve as a good template IMO. Tricky part will be finding enough free ROM space for that and boring part doing the cycle calculations and test. Could take a while until I find the time to tackle this, so don't expect a quick fix :)

so long,

Hias

#42 gargoyle OFFLINE  

gargoyle

    Chopper Commander

  • 124 posts

Posted Wed Apr 19, 2017 4:13 PM

Can't seem to find the original video showing the U1MB PBI BIOS/Megaspeedy issue (presumably got pulled), but it's a shame RWTEST wasn't tried before high speed transfers using Hias' OS were announced working. ;) Anyway: I'm open to any compromise/patch necessary to work around the problem.

 

I have videos showing the difference between PBI BIOS and OS High-Speed modes. The first video shows a copy operation from a stock 1050 (d2:) to a Megaspeedy 1050 (d1:) with PBI BIOS turned ON and high-speed selected:

 

 

The second video shows the same test with OS High-Speed turned ON and PBI BIOS turned OFF. The copy works but as Hiassoft pointed out it is slow and sounds kind of different.

 

The megaspeedy drive is in E1 mode by the way.


Edited by gargoyle, Wed Apr 19, 2017 4:17 PM.


#43 HiassofT OFFLINE  

HiassofT

    Dragonstomper

  • 998 posts
  • Location:Salzburg, Austria

Posted Wed Apr 19, 2017 4:52 PM

I have videos showing the difference between PBI BIOS and OS High-Speed modes. The first video shows a copy operation from a stock 1050 (d2:) to a Megaspeedy 1050 (d1:) with PBI BIOS turned ON and high-speed selected:
 
The second video shows the same test with OS High-Speed turned ON and PBI BIOS turned OFF. The copy works but as Hiassoft pointed out it is slow and sounds kind of different.

The megaspeedy drive is in E1 mode by the way.

Thanks a lot for the videos!

In the second video you can hear the rather ugly sound when writing to the megaspeedy. Each sector is first tried with highspeed, then with standard speed. This is what I need to fix (in speedy firmware). But it's good to know that at least the error-fallback to standard speed is working fine with my highspeed code :)

so long,

Hias

#44 gargoyle OFFLINE  

gargoyle

    Chopper Commander

  • 124 posts

Posted Wed Apr 19, 2017 5:26 PM

Thanks a lot for the videos!

Each sector is first tried with highspeed, then with standard speed. 

so long,

Hias

 

That's right, Aspeqt log shows those speed change tries on each write.



#45 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 12,215 posts
  • Location:United Kingdom

Posted Thu Apr 20, 2017 12:45 AM

@Hias: can't recall offhand why standard speed fallback was taken out of PBI implementation, but it was deliberate and there was good reason for it (buried in 500 posts of PMs). Can you recall?

#46 HiassofT OFFLINE  

HiassofT

    Dragonstomper

  • 998 posts
  • Location:Salzburg, Austria

Posted Thu Apr 20, 2017 8:08 AM

Hi Jon!
 

@Hias: can't recall offhand why standard speed fallback was taken out of PBI implementation, but it was deliberate and there was good reason for it (buried in 500 posts of PMs). Can you recall?

I can't quite recall either but it could have had something to do with (HISIO+)SIO2BT modes where speed-switching would be counter-productive.

But it could well be that you just forgot to re-add speed-switching in HISIO mode or that there's a small bug buried somewhere. I don't think there's any reason to not use HISIO mode, with speed switching, like before.

so long,

Hias

Edited by HiassofT, Thu Apr 20, 2017 8:09 AM.


#47 HiassofT OFFLINE  

HiassofT

    Dragonstomper

  • 998 posts
  • Location:Salzburg, Austria

Posted Thu Apr 20, 2017 8:08 AM

... argh, wrong button

Edited by HiassofT, Thu Apr 20, 2017 8:09 AM.


#48 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 12,215 posts
  • Location:United Kingdom

Posted Thu Apr 20, 2017 8:22 AM

I can't quite recall either but it could have had something to do with (HISIO+)SIO2BT modes where speed-switching would be counter-productive.

But it could well be that you just forgot to re-add speed-switching in HISIO mode or that there's a small bug buried somewhere. I don't think there's any reason to not use HISIO mode, with speed switching, like before.


I've had a look at the source and compared it to your original code and the pathway for fallback is basically the same unless SIO2BT is enabled:

ChkDr
	dec DRETRY	; any more command retries?
	beq EndCmd	; no, we are finished

	cpy #Err.Device
	beq GoDr	; don't fallback speed on command errors
	bit SIOType	; don't fallback speed if SIO2BT is enabled
	bpl FallBack
	lda MySpeed	; SIOSpeed
	cmp #5
	bcs GoDr	; only fallback with BT enabled if the divisor is 4 or less
FallBack
	lda #STDSPD	; try it with standard speed this time
	sta MySpeed

GoDr
	lda #DEFCRETRY
	sta CRETRY
	jmp DRetLp	; yes, try it again
EndCmd

Bit 7 of SIOType signifies SIO2BT mode is enabled. When it is, you can see fallback to standard speed only occurs if the divisor is 4 or less (this was your recommendation, which I did manage to locate in the discussion).

 

So one possible scenario in which problems may occur is when SIO2BT mode is enabled (inadvertently or deliberately). Another possibility is old or mismatched firmware. I see main BIOS 1.20 used in the video above and looking through the changelog (we're now at v.1.25) I can see that SIO2BT options changed between 1.20 and 1.21. A mismatch between the PBI BIOS and main BIOS would almost certainly cause troubles there (which is one reason I provide a complete 64KB firmware binary).

 

@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/...date_071216.zip



#49 JoSch ONLINE  

JoSch

    Moonsweeper

  • 372 posts
  • Location:Germany

Posted Thu Apr 20, 2017 8:44 AM

 

@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/...date_071216.zip

And make a backup of your current BIOS ROMs, so that Jon can debug resp. you can redo your test ;-)



#50 _The Doctor__ OFFLINE  

_The Doctor__

    River Patroller

  • 2,040 posts
  • Location:10-0-11-00:02

Posted Thu Apr 20, 2017 11:33 AM

Just to be sure, while there may or may not be an issue as is being discovered on what's in PBI bios ...

The MegaSpeedy itself has a timing issue with NTSC machines the firmware for the Megaspeedy needs to be repaired if possible else the timing circuits may need update and firmware adjusted accordingly for the megaspeedy in any event...






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users