Strange U1MB issue

[_The Doctor__]

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 April 16, 2017 by _The Doctor__

[flashjazzcat]

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.

[Bikerbob]

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 April 17, 2017 by Bikerbob

[flashjazzcat]

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.

[Bikerbob]

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

[HiassofT]

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 April 18, 2017 by HiassofT

[HiassofT]

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.

 

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

 

so long,

 

Hias

[flashjazzcat]

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...

[HiassofT]

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

[flashjazzcat]

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

[HiassofT]

Last tests for today:

 

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

 

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

[+CharlieChaplin]

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)...

 

SPEEDY6.PDF

Edited April 19, 2017 by CharlieChaplin

[Bikerbob]

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 April 19, 2017 by Bikerbob

[phaeron]

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.

[flashjazzcat]

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.

[HiassofT]

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

[gargoyle]

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:

 

https://youtu.be/lDaql3QGvm4

 

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.

 

https://youtu.be/smZOKKSgNUE

 

The megaspeedy drive is in E1 mode by the way.

Edited April 19, 2017 by gargoyle

[HiassofT]

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

[gargoyle]

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.

[flashjazzcat]

@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?

[HiassofT]

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 April 20, 2017 by HiassofT

[HiassofT]

... argh, wrong button

Edited April 20, 2017 by HiassofT

[flashjazzcat]

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/wp-content/uploads/2016/12/Ultimate1MB_Firmware_Update_071216.zip

[JoSch]

 

@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

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

[_The Doctor__]

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...