AiC Форум

**Opk** 06 дек 2005, 00:00

быстрее всего adf просто сырые данные

**Wanderer** 06 дек 2005, 00:55

Достал меня ASm68k. Вот бы где девпак поиметь. И еще - кто нибудь E использует?

**Opk** 06 дек 2005, 01:10

planetemu.net там в разделе Амига и в подразделе программ ищи.

**Wanderer** 06 дек 2005, 01:52

Спасибо. Попробую запустить.

**Vinnny** 06 дек 2005, 12:31

[quote="Wanderer"]Амига тоже читает секторами.[/quote]
чудак-человек. тебе ж говорят - амига читает целиком дорожку (аппаратно), потом идёт разбивка на сектора (программно). таким образом читаются любые дискеты с любыми параметрами, а потом лишь рассортировывается считанная инфа на сектора (так и пишутся дрова для чтения дискет с пэцэ, мак, zx).
на аминете например есть архив trd-maker.lha с исходниками на эту тему...

**mike** 06 дек 2005, 13:08

[quote="Wanderer"]
Ну уж нет. Рекомендую внимательно почитать принципы работы вообще дисковых подсистем. На самом деле можно заставить и PC читать сразу всю дорожку, тем более что это не потребует никаких переделок - всего лишь выделить больший буфер DMA. Амига тоже читает секторами. А чтение трека целиком обосновано как раз самой проблемой. А вся проблема в СКОРОСТИ записи. Амига оперирует значением 150 кб в сек, а PC 250, 300 и 500 Кб в сек. Соответственно низкая скорость и обусловила применения считывание целиком всей дорожки. Эта же причина привела к невозможности пометить сбойный сектор, так как при возникновении такой ошибки сихронизация нарушается и трек целиком считан быть не может. Практически можно было бы выйти и из этой проблемы применением прямого чтения потока с диска.Для этого в контроллере PC есть сответствующий режим. Насколько я понял, этот режим часто применялся программами для защиты информации от копирования.[/quote]

Если бы можно было бы, то UAE давно бы это имела, они уже не первый год этим занимаются, и поверь многое об этом знают. Откуда такие данные по скорости обмена, у тебя взялись, я не знаю, но пока амига работает с дисководом быстрее чем писюк - на глаз видно. Следовательно у тебя очень ошибочная информация. Ещё раз настоятельно рекомендую почитать документацию к контроллерам.

**Wanderer** 06 дек 2005, 19:58

Все правильно. Амига пишет и читает целиком весь трек. Без какого либо деления на сектора. То есть разметка не используется в отличии от PC. Для этого используется часть Гари и один из каналов Паулы. Для передачи информации применяется один из каналов ПДП толстого Агнуса. Но! Кто сказал что нельзя обычный стандартный контроллер PC дисковода перевести в тот же режим непрерывного чтения трека без разметки. Тем более что PLL позволяет читать дискеты с одинарной плотностью? Другое дело, что при чтении этого трека надо игнорировать флаги MA и MD. Весь вопрос в том, осталась ли эта возможность в современных интегрированных контроллерах.
Если кому интересно
http://elancev.narod.ru/texno/dsk_ap/dsk_ap.htm

**anny** 06 дек 2005, 23:38

Wanderer, яб на твоем месте естноб никого не слушал, а просто взял бы и написал тулзень которая на пц для начала читает ffs дискеты :) Я могу даже подсобить в целом

**mike** 07 дек 2005, 13:29

[quote="anny"]Wanderer, яб на твоем месте естноб никого не слушал, а просто взял бы и написал тулзень которая на пц для начала читает ffs дискеты

Я могу даже подсобить в целом[/quote]

Вот правиьно, и я бы тоже спасибо сказал, за такую тулзень, ибо она не лишняя.

**Wanderer** 07 дек 2005, 17:23

Эх... Написал.... Если бы все было так просто. У меня машины с MSDOS просто нет. А из под XP больше полутора секторов не читает - прерывание по таймеру присходит. Отключил я его - и винда брякнулась. Так что даже проверить мне не начем. А прямое бессекторное чтение было реализовано довольно давно авторами известной системы защиты от копирования. Помню еще на УКНЦ парень написал году в 88м защиту основанную именно на бессекторной записи, наподобии записи на магнитную ленту. Тогда на PC записанное прочитать удалось. Но вот, как назло, исходника не осталось.

**Wanderer** 07 дек 2005, 17:35

http://adfsender.stoeggl.com/
Помоему это то что мне надо.

**Wanderer** 08 дек 2005, 00:58

Мда. Моет я что то не понимаю. Не работает это у меня. Может кто попробует?

**anny** 08 дек 2005, 14:08

Wanderer
под xp чтобы msdos сделать, надо только msdos бутблок (могу выслать)
и в boot.ini написать:
[code]
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Winda XP" /fastdetect
C:\bootsect.dos="Mega-DOS"
C:\bootsect.lin="Linux"
[/code]

И будет чистый дос, грузи дос навигатор или нортон и пошло поехало.

**Wanderer** 09 дек 2005, 00:26

Мда. И как, на NTFS работать будет? У меня давно нет разделов FAT.
Кстати:
[code]
If you switch to the density corresponding to the disk density (for example 250 000 bits/sec for a 1 MB double-density disk), you’ll get either the actual data or the MFM synchronization bits.

Here’s the example:

1 0 0 1 0 0 1 0 0 1 0 1 0 1 0 0 The full data on disk.
| | | | | | | |
0 1 0 0 1 1 1 0 4Eh => character ‘N’
| | | | | | | |
1 0 0 1 0 0 0 0 90h => MFM synchronization bits for ‘N’

With the actual data, you can reconstruct, or simply ignore, the MFM synchronization bits, except for the MFM synchronization words. However, these words can be detected by analysis of sector headers. For example 0000A1A1 may be the beginning of an Amiga sector, with its two standard MFM synchronization words. To verify it is a valid Amiga sector, CRC can be checked on the whole header. This approach is efficient enough to read standard tracks without CRC errors nor non-standard sector headers.

With the MFM synchronization bits, you’re out of luck because you can’t reverse them to actual data. The only way to get the actual data is to read the disk once again, until actual data is read as above. In this example, when reading 90h (MFM synchronization bits for 4Eh), it can correspond to the following non-encoded data:

1 0 0 1 0 0 0 0 => synchronization bits 90h.
0 1 0 0 1 0 1 ? |
0 1 0 0 1 1 0 1 | possible data resulting in a synchronization value of 90h.
0 1 0 0 1 1 1 ? |
|
You can’t tell whether this bit was ‘0’ or ‘1’.

So the value 4Eh is only a possibility among others.

Sector data are always aligned, so you will be able to extract at least a full sector with luck. The Amiga always writes a full track at once, so changes in the alignment may only appear once in the whole track, where the Amiga stopped writing the track. However, the PC behaves differently: it will format a whole track at once, but it will write only one sector at a time on a formatted disk. This can lead to a change in the alignment before the sector data (just before the synchronization mark which corresponds to 12 * MFM ”00h”, then 3 * raw ”4489h”, then MFM “FBh”), and after the sector data (just after the 2 CRC bytes).
[/code]
Это взято из описания работающей программки читающей диск Амиги.

**anny** 09 дек 2005, 15:14

Wanderer
Я в том смысле, что если _реально_ хочешь попробовать писать, то естно сделать кусок фатовый и тд и тп не проблема. Т.е. то что "я не пишу потому как нету msdos" это не отмаза :)

AiC Форум

Два вопроса

Кто сейчас на конференции