Rybags

The RPM test I was using is the speed test under main menu option 2. I feel it's not working because the both drives won't even read a sector for whatever reason. Another thought I had is to try and use a PC power supply, has anyone tried that before?

Yep... like ChipRam vs FastRam on the Amiga. Though my idea before would probably be just as complex.

Well, in theory with the lower latency Ram in use they could have added a little extra hardware to buffer CPU accesses and done refresh and DMA transparently.

I was using an ED disk that has games on it (and doesn't matter if it gets wiped). I have no such luxury of fresh formatted disk or a known unformatted one thanks to not having any operational drives. The motor speed test just sat there and returned nothing.

On both drives - motor start test seems to do a seek without the drive spinning but then starts spinning a couple of seconds later (and still fails)

OK - booted diags then did the drive swap. Motor Start test fails as does Motor Speed "TO HIGH" and fail for Step/Settle and Track 00 sensor test. Running Track 00 sensor test via option 2 passes though.

The impact as I see it would be on kernal and DLI based stuff. Likely most RastaConverta images wouldn't work properly. The obvious solution though would have been to put a control bit in an Antic register to select small/big refresh.

Freddie just replaces a bunch of generic LS series ICs that were involved in memory selection (mostly Ras/Cas type stuff). It does a whole bunch of stuff in less space and probably less power consumption but doesn't really add any new features. It runs at ~ 14 MHz which gets divided down - NTSC uses ~ 3.59 MHz for video generation and that speed is also half a machine cycle which can provide the Ras/Cas transition. Then 1.79 MHz for the CPU. But we still have memory refresh and Antic DMA like older machines. In theory the XL/XE could probably have gotten away with less refresh cycles, like 5 per scanline instead of 9 but then you'd have gotten a small performance gain with the tradeoff that a whole bunch of software (mostly games) wouldn't work the same any more.

Can't say I've heard of such a thing. I'll try leaving it but not holding high hopes.

Other drive (with restricted pad movement and track zero sensor clearly accessable) - the volt readings are more normal with 19.5 / 12 on one and 9.8 / 5 on the other.

About 9.1 V AC coming from the PSU. The 7812 seems normal with about 19.9 in and a little over 12 out. But the 7805... about 9.9 in and only 4.8 coming out - I assume using the screw that attaches it to the heatsinking point is OK as a ground point? Computer itself is fine - it boots up via SIO2SD as D1: and the 1050s are set to other IDs.

No go with the diag disk - you have to have it on actual physical media to work it would seem. I'll see what I can do about getting some voltage readings - starting to suspect the PS as it seems unlikely both drives would fail with the same problem at the same time.

No. The drives behave otherwise normally (power up, seek when reading etc) but every read attempt has failed aside from that directory attempt earlier. I'll see if I can DL it and boot from SIO2SD.

I've got 2 x stock 1050s, both have had near perfect behaviour always, only needing a head clean once in a while (open up, swab with isopropyl). Today I've used them for the first time in probably 3 years, maybe a bit longer. I managed to get a directory on one of them after a few failed read attempts on other floppies, subsequent attempts fail. Tried various disks, likely they are all good. Most kept in my bedroom, generally never high humidity but sometimes low and high temperatures. But the drives, seem to spin up fine and the seeking seems normal also. But any attempt at a disk read gets the seek 0/reseek/retry thing and the usual Error 144. Even formatting fails - it does the high speed write and head step every ~ 1.5 seconds but the format fails eventually after retrying a couple of times. Visual inspection inside - the heads on one looked a bit dirty and both came up fine. Very slight bulge on the big caps on one drive. Each drive has a different mech by the looks - one has the felt pad that barely seperates off the head and the other has the one that can open up beyond 90 degrees. I've only got the single PS that I've used on both - though I guess I could try a 400 PS though I think it might be underrated for the task? But back to the issue - any ideas? Speed, track 0 sensor, alignment? Something else?

Just realised this is in the wrong section - can we delete this thread?

I've got 2 x stock 1050s, both have had near perfect behaviour always, only needing a head clean once in a while (open up, swab with isopropyl). Today I've used them for the first time in probably 3 years, maybe a bit longer. I managed to get a directory on one of them after a few failed read attempts on other floppies, subsequent attempts fail. Tried various disks, likely they are all good. Most kept in my bedroom, generally never high humidity but sometimes low and high temperatures. But the drives, seem to spin up fine and the seeking seems normal also. But any attempt at a disk read gets the seek 0/reseek/retry thing and the usual Error 144. Even formatting fails - it does the high speed write and head step every ~ 1.5 seconds but the format fails eventually after retrying a couple of times. Visual inspection inside - the heads on one looked a bit dirty and both came up fine. Very slight bulge on the big caps on one drive. Each drive has a different mech by the looks - one has the felt pad that barely seperates off the head and the other has the one that can open up beyond 90 degrees. I've only got the single PS that I've used on both - though I guess I could try a 400 PS though I think it might be underrated for the task?

Rear Guard was pretty good. I'd be pushing it to name 10 Basic games that came on disk or tape that you had to pay for though.

If the device doesn't power up fast enough to boot - a trick to use can be to just press Reset before the SIO poll finishes (fart sound) and it'll coldstart again.

The need for faster RAM is only to be able to hide the refresh and video memory accesses. That ratio sounds almost right - DMA off with 9 cycles refresh on all lines should be about 1.21 for NTSC Atari vs BBC.

Remember Cyber Paint on the ST? It could do animation sequences - the compression used was a mix of RLE and XOR of the data that had to change. For something that's moving a little bit per frame it can be a pretty efficient method. I don't know if there's been any use of it or examples available on the 8-bit though.

The interrupt thing - maybe not such a big problem, just replicate the handlers in each bank. For me the obvious thing to have with a >16K OS would be a built in Dos with minimal Ram footprint. And a decent monitor as well. Just between those two you might be looking at most of the Rom space used (also noting you'd have to replicate the built in character sets and possibly the FP Rom portion).

Getting late here - I've made a quick and dirty bench that is almost spot on 30 seconds runtime on (emulated) BBC Model B. It makes a good baseline for comparison since it's supposedly (excactly?) 2 MHz without impediments of DMA and refresh stealing CPU cycles. I'll convert to run on Atari, C64 and Plus/4 tomorrow if I get time (unless someone wants to do so first). The BBC TIME variable is supposedly accurate enough, using proper timer hardware and not a 50 Hz video interrupt that's not really 50 Hz.

Having only 32K Ram was something of a handicap - we had them in school also - by the time you take the memory of the highest graphics mode away it doesn't leave much, although having the DOS in Rom was helpful in keeping that part of the overhead down.

VBXE follows stock Atari video timings (which are also common to most consoles/computers of that era). For PAL you're actually getting a 312p signal instead of 625i - NTSC is 262p instead of 525i. When you hear references to 240p it's just the normal possible display area with the remaining lines usually being black. I've actually got a GBS8200 V4 which I've used with my VBXE and a normal monitor and it worked fine. As for other video converters, it's often a case of test it and see.

My (somewhat older) version of WinRar managed 1681 bytes (and 1703 with a quick play with 7Zip) Though I suspect it'd be handicapped for smaller files somewhat with it's normal overheads and large dictionary size (I forced it to 64K which was the smallest available) I think for larger sizes the advantage on the Atari would vanish and probably go the other way.