На самом деле если эмиттер слабо легировать - то он не будет эмиттером и транзистор не будет транзистором.
Вполне себе будет, но плохим. Убедиться в этом можно, померяв мультиметром бету у инверсно включенного транзистора -- вместо сотен для какого-нить bc547 будут десятки. Но будут. Ну и в некоторых биполярных процессах, заточенных на npn-транзисторы, именно так иногда и делают плохие, но всё же pnp-транзисторы.
По поводу статьи -- без хотя бы рукоразмахивательного и "на пальцах" введения в зонную теорию полупроводников всё равно не сильно лучше чем с мексиканцами получилось.
Последний раз когда я проверял btrfs, она просто конско тормозила с образами дисков для виртуалок. И у неё ещё до сих пор проблемы с raid5 или 6, вроде как. в ZFS со всем этим проблем нет. С другой стороны, btrfs нативная для линукса и с неё тот замечательно бутится. С ZFS забутиться удастся только с помощью извратов в initramfs. Администрирование btrfs тоже по ощущениям как-то более нативно что ли, чем вычурные и многословные конструкции zfs. Понятия 'датасетов' тоже в zfs слишком абстрактны, в btrfs imho это сделано лучше. Наконец, zfs умеет в нативное шифрование, а в btrfs несмотря на как-то раз обещанное шифрование, до сих пор ничего. В btrfs есть дефрагментация всего чего только можно, в zfs ничего.
Поэтому приходится держать обе две.
А вообще очень показательно, как sun и далее сообщество смогли в zfs, линуксовое сообщество смогло в btrfs, а целый большущий микрософт в свой похожий велосипед -- не смог.
И единственнное, что может (и должен!) сделать уважающий себя разработчик
То есть если разработчик этого не делает (потому что ему нечем), то он себя не уважает, а что контора это не внесла в планы и не закупила оборудование (пушо например денег нет таких), так то всё равно разработчик виноват?
В моей практике неработающий (периодически срывающийся) HDMI выход был 1 раз, для его отладки у кого-то брали попользоваться какое-то астрономически дорогое барахло, а проблема оказалась в том, что программисты нагуевертили с настройкой PLL. И то оборудование никак не помогло это выявить, хотя показывало всякие красивые там глазковые диаграммы и проч.
И выше уже сказали, что куча народу на полулюбительском уровне (без проверки на "соответствия стандартам") вполне себе клепают PCIe и HDMI и что там ещё. И как-то работает. Вот пусть "соответствием стандартам" с осциллографами на 100 гигагерц упражняются богатые конторы.
Ну а про кабель смешно, я лично повыкидывал несколько таких кабелей. Не вижу тут проблем.
А ну да, давайте 120 герц возьмём, а потом ещё стерео, и даже 10 бит на цвет можно взять ради страшной циферки. Если кто-то (полу-)кустарно делает в своем девайсе fullHD hdmi выход, то это будет во-1 какая-нибудь микросхема HDMI передатчика, в которую входят просто 24 сигнала с RGB на частоте 148.5 МГц, во-2 там не будет никаких 120 Гц и 3д, в-3 длины собственно проводников с 1.5 гигабитами/c будут, очевидно, максимально короткими: микросхема рядом с разъёмом.
Это конечно верно, если цель -- сделать HDMI fullHD видеовыход. Если цель иная, например напугать кого-то гигабитами, то да, 13 Гб/с, даже и не мечтайте осциллографом потыкать или на коленке сделать.
PCIe, да хоть не четвертой, а третьей ревизии
О, вам, как любителю, перестало хватать скоростей PCIe gen.1 со своими 2.5 гигабитами/с на лейн?
Те, кому этого хватило бы, могут купить дешёвую девборду c FPGA.
Гонево какое-то. Это примерно чуть менее чем 150 МГц пикселклок, с учётом 3 линий передачи и кодирования 8->10 получается менее полутора гигабит в секунду в каждом канале из трёх.
Вот кстати да, почему автор рассказывает нам про RSA, а не про более современные методы на эллиптических кривых. Ну и его предложение про "перебор приватного ключа" тоже повеселило -- видимо он совсем не в курсе ну хотя бы про основы RSA. А ещё, как уже выше заметили, повеселил рассказ про кейлоггеры и офигенно надёжный незашифрованный приватный ключ там же, где у него кейлоггеры крадут пароли. Он точно безопасник, а не ИБДшник?
"Профессионально разработанные" cortex-m аппаратно пушат кучу (но не все) регистров и точно так же тратят на это время, но только уже безусловно и всегда. А потом ещё и компитятор ручками сохраняет оставшиеся, если функция обработчика сложная с кучей расчётов, не лезущих в сохранённые аппаратно. Ну и наконец, никто и ничто не мешает впилить в конкретную эмбедскую risc-v корку расширение, подменяющее caller-saved регистры при входе в обработчик.
Вот странно. У вас "ой спорно", а у толпы олдов-фанатов пдп-11 не спорно...
Хотя со многим я согласен, достаточно было бы 1.5-адресных команд, как в 68k сделали и огромный косяк с ADC/SBC, который аж не поправили, а повторили в ваксе.
Установка флагов командами MOV, CLR, COM - диверсия, которую практически все позднейшие архитектуры, имеющие флаги условий, устранили. X86, ARM, SPARC, M68k, POWER - нигде такого нет.
Не знаю почему это "диверсия", и откуда вы взяли что в 68к этого нет (как раз очень есть). И присмотритесь к арму или power, может и там оно окажется (опциональным для каждого опкода).
"68k" это "x86", а первый процессор семейства 68k это 68000. И как конкурент 286 он очень даже -- появился раньше, адресовал память сразу нормально, а не убого как 286, кусками по 64к.
про прерывания так что то я и не понял. внешний девайс может в себя включать кучу всякого железа для манипуляций прерываниями
Ну очевидно же. Внешний девайс выставляет свое прерывание на /INT, если в этот же момент ула решит поддёрнуть своё, то оно потеряется.
может даже сделать di:halt
Программе может потребоваться запретить прерывания на какое-то (короткое) время. Если в этот момент ула поддёрнет своё прерывание, то оно тоже потеряется, т.к. не висит до момента очистки процессором, а само по себе кончается. В этом и есть проблема
в 128 два экранных буфера 0x4000, другой с 0xС000 переключаться битиком.
Нет конечно же, там 2 экранных буфера, каждый в своей собственной страничке 16к. Вот правда одна из них всегда воткнута с адреса 0x4000 и её можно воткнуть в 0xc000, а другая -- только в 0xc000 и втыкается. Как результат, если нужно работать с 2 экранными буферами, то извольте их втыкать в 0xc000,после чего в процессе рисования расширенная память оказывается недоступна. Или делайте промежуточный внеэкранный буфер а потом копируйте.
в 48 столько памяти на экран - никтобы не понял.
Фактически, там и так 16 килобайт видеопамяти было, но ула могла вынимать из них только те самые 6912. А если сделать 2 экранных буфера, это не значит что теперь нельзя использовать только один, всё остальное могло бы оставаться точно таким же (в т.ч. начало васика c 0x5c00 и т.д.).
"байт атрибута на байт пикселей" многие хотели, но опять же не в 48К же.
Почему это "не в 48к же"? Какая логика стоит за таким выводом? В том же таймексе с теми же 48к памяти вполне себе сделали.
А вот про прерывание не понял/не помню, в чем была проблема в имеющейся реализации?
Представьте, что внешний девайс тоже захочет давать прерывания. Или что программа захочет по какой-то надобности запретить прерывания на скажем 10 мкс. Результатом будет неиллюзорная возможность терять кадровые.
А вот нифига. Разлиновка экрана была следствием того, что "чипсет" спектрума читал память в "page mode": один раз выдавал RAS-адрес и потом 2 раза читал с разных CAS-адресов. Благодаря этому в моменты чтения пикселей и атрибутов Z80 хоть и с тормозами, но мог продолжать работать с видеопамятью.
Я имел в виду например следующее:
можно было бы сделать 2 экранных буфера, например один с адреса 0x4000, другой с 0x6000.
можно было бы дополнительно сделать цветовой режим "байт атрибута на байт пикселей"
можно было бы прерывание сделать нормальным (для чего достаточно было всего лишь битик статуса впендюрить в УЛу, и снимать прерывание не тупо через короткое время, а только по факту очистки того бита статуса)
Одна часть "ракеты-носителя" была прикручена к шатлу в виде большого оранжевого бака, а другая часть после выработки всего топлива из того бака -- маршевые двигатели -- являлась собственно частью конструкции шатла и становилась мёртвым грузом на всё остальное время полета.
Далее, что шатл, что буран с момента отключения маршевых двигателей находились на незамкнутой орбите, и далее довыведение осуществляли собственными двигателями орбитального маневрирования. Так что формально "самостоятельный подъём на орбиту" осуществлял и буран тоже.
С какого перепоя дважды-то? В slog идут только синхронные записи.
Кто-то уже проверил?
Как определить что CPU отказал/сбойнул?
Если определили, как понять, с какого момента?
Что, и даже шокером в плату не убить?
А вот тут воспринимают, странно https://www.allaboutcircuits.com/textbook/designing-analog-chips/analog-devices/the-case-of-the-lateral-pnp-transistor/
Я даже и не хочу эту модель разбирать. Я сказал что сказал, причём тут "я не замечаю в мексиканской модели" -- не очень понял.
Вполне себе будет, но плохим. Убедиться в этом можно, померяв мультиметром бету у инверсно включенного транзистора -- вместо сотен для какого-нить bc547 будут десятки. Но будут. Ну и в некоторых биполярных процессах, заточенных на npn-транзисторы, именно так иногда и делают плохие, но всё же pnp-транзисторы.
По поводу статьи -- без хотя бы рукоразмахивательного и "на пальцах" введения в зонную теорию полупроводников всё равно не сильно лучше чем с мексиканцами получилось.
Последний раз когда я проверял btrfs, она просто конско тормозила с образами дисков для виртуалок. И у неё ещё до сих пор проблемы с raid5 или 6, вроде как. в ZFS со всем этим проблем нет. С другой стороны, btrfs нативная для линукса и с неё тот замечательно бутится. С ZFS забутиться удастся только с помощью извратов в initramfs. Администрирование btrfs тоже по ощущениям как-то более нативно что ли, чем вычурные и многословные конструкции zfs. Понятия 'датасетов' тоже в zfs слишком абстрактны, в btrfs imho это сделано лучше. Наконец, zfs умеет в нативное шифрование, а в btrfs несмотря на как-то раз обещанное шифрование, до сих пор ничего. В btrfs есть дефрагментация всего чего только можно, в zfs ничего.
Поэтому приходится держать обе две.
А вообще очень показательно, как sun и далее сообщество смогли в zfs, линуксовое сообщество смогло в btrfs, а целый большущий микрософт в свой похожий велосипед -- не смог.
То есть если разработчик этого не делает (потому что ему нечем), то он себя не уважает, а что контора это не внесла в планы и не закупила оборудование (пушо например денег нет таких), так то всё равно разработчик виноват?
В моей практике неработающий (периодически срывающийся) HDMI выход был 1 раз, для его отладки у кого-то брали попользоваться какое-то астрономически дорогое барахло, а проблема оказалась в том, что программисты нагуевертили с настройкой PLL. И то оборудование никак не помогло это выявить, хотя показывало всякие красивые там глазковые диаграммы и проч.
И выше уже сказали, что куча народу на полулюбительском уровне (без проверки на "соответствия стандартам") вполне себе клепают PCIe и HDMI и что там ещё. И как-то работает. Вот пусть "соответствием стандартам" с осциллографами на 100 гигагерц упражняются богатые конторы.
Ну а про кабель смешно, я лично повыкидывал несколько таких кабелей. Не вижу тут проблем.
А ну да, давайте 120 герц возьмём, а потом ещё стерео, и даже 10 бит на цвет можно взять ради страшной циферки. Если кто-то (полу-)кустарно делает в своем девайсе fullHD hdmi выход, то это будет во-1 какая-нибудь микросхема HDMI передатчика, в которую входят просто 24 сигнала с RGB на частоте 148.5 МГц, во-2 там не будет никаких 120 Гц и 3д, в-3 длины собственно проводников с 1.5 гигабитами/c будут, очевидно, максимально короткими: микросхема рядом с разъёмом.
Это конечно верно, если цель -- сделать HDMI fullHD видеовыход. Если цель иная, например напугать кого-то гигабитами, то да, 13 Гб/с, даже и не мечтайте осциллографом потыкать или на коленке сделать.
О, вам, как любителю, перестало хватать скоростей PCIe gen.1 со своими 2.5 гигабитами/с на лейн?
Те, кому этого хватило бы, могут купить дешёвую девборду c FPGA.
Гонево какое-то. Это примерно чуть менее чем 150 МГц пикселклок, с учётом 3 линий передачи и кодирования 8->10 получается менее полутора гигабит в секунду в каждом канале из трёх.
Вот кстати да, почему автор рассказывает нам про RSA, а не про более современные методы на эллиптических кривых. Ну и его предложение про "перебор приватного ключа" тоже повеселило -- видимо он совсем не в курсе ну хотя бы про основы RSA. А ещё, как уже выше заметили, повеселил рассказ про кейлоггеры и офигенно надёжный незашифрованный приватный ключ там же, где у него кейлоггеры крадут пароли. Он точно безопасник, а не ИБДшник?
Очевидно же, они перешли к O(N^2 * 2^(-N))! Новое слово в computer science! :)
"Профессионально разработанные" cortex-m аппаратно пушат кучу (но не все) регистров и точно так же тратят на это время, но только уже безусловно и всегда. А потом ещё и компитятор ручками сохраняет оставшиеся, если функция обработчика сложная с кучей расчётов, не лезущих в сохранённые аппаратно. Ну и наконец, никто и ничто не мешает впилить в конкретную эмбедскую risc-v корку расширение, подменяющее caller-saved регистры при входе в обработчик.
Вот странно. У вас "ой спорно", а у толпы олдов-фанатов пдп-11 не спорно...
Хотя со многим я согласен, достаточно было бы 1.5-адресных команд, как в 68k сделали и огромный косяк с ADC/SBC, который аж не поправили, а повторили в ваксе.
Не знаю почему это "диверсия", и откуда вы взяли что в 68к этого нет (как раз очень есть). И присмотритесь к арму или power, может и там оно окажется (опциональным для каждого опкода).
"68k" это "x86", а первый процессор семейства 68k это 68000. И как конкурент 286 он очень даже -- появился раньше, адресовал память сразу нормально, а не убого как 286, кусками по 64к.
х87 даже синусы считает неточно, попробуйте посчитать sin(M_PI) при помощи SSE(2) и при помощи х87.
А если вам не хватает 53 бит мантиссы, попробуйте для начала https://en.wikipedia.org/wiki/Double-double_(arithmetic)#Double-double_arithmetic
Ну очевидно же. Внешний девайс выставляет свое прерывание на /INT, если в этот же момент ула решит поддёрнуть своё, то оно потеряется.
Программе может потребоваться запретить прерывания на какое-то (короткое) время. Если в этот момент ула поддёрнет своё прерывание, то оно тоже потеряется, т.к. не висит до момента очистки процессором, а само по себе кончается. В этом и есть проблема
Нет конечно же, там 2 экранных буфера, каждый в своей собственной страничке 16к. Вот правда одна из них всегда воткнута с адреса 0x4000 и её можно воткнуть в 0xc000, а другая -- только в 0xc000 и втыкается. Как результат, если нужно работать с 2 экранными буферами, то извольте их втыкать в 0xc000,после чего в процессе рисования расширенная память оказывается недоступна. Или делайте промежуточный внеэкранный буфер а потом копируйте.
Фактически, там и так 16 килобайт видеопамяти было, но ула могла вынимать из них только те самые 6912. А если сделать 2 экранных буфера, это не значит что теперь нельзя использовать только один, всё остальное могло бы оставаться точно таким же (в т.ч. начало васика c 0x5c00 и т.д.).
Почему это "не в 48к же"? Какая логика стоит за таким выводом? В том же таймексе с теми же 48к памяти вполне себе сделали.
Представьте, что внешний девайс тоже захочет давать прерывания. Или что программа захочет по какой-то надобности запретить прерывания на скажем 10 мкс. Результатом будет неиллюзорная возможность терять кадровые.
А вот нифига. Разлиновка экрана была следствием того, что "чипсет" спектрума читал память в "page mode": один раз выдавал RAS-адрес и потом 2 раза читал с разных CAS-адресов. Благодаря этому в моменты чтения пикселей и атрибутов Z80 хоть и с тормозами, но мог продолжать работать с видеопамятью.
Я имел в виду например следующее:
можно было бы сделать 2 экранных буфера, например один с адреса 0x4000, другой с 0x6000.
можно было бы дополнительно сделать цветовой режим "байт атрибута на байт пикселей"
можно было бы прерывание сделать нормальным (для чего достаточно было всего лишь битик статуса впендюрить в УЛу, и снимать прерывание не тупо через короткое время, а только по факту очистки того бита статуса)
Одна часть "ракеты-носителя" была прикручена к шатлу в виде большого оранжевого бака, а другая часть после выработки всего топлива из того бака -- маршевые двигатели -- являлась собственно частью конструкции шатла и становилась мёртвым грузом на всё остальное время полета.
Далее, что шатл, что буран с момента отключения маршевых двигателей находились на незамкнутой орбите, и далее довыведение осуществляли собственными двигателями орбитального маневрирования. Так что формально "самостоятельный подъём на орбиту" осуществлял и буран тоже.