Вид для печати
Я говорил, что есть исходники UZIX v 1.0 и нет исходников UZIX v2.0, и о том, что UZIX v 1.0 - это UZI, заточенный под MSX. Компилятор для Uzix использовался такой: "The source code is written mostly in C, and was compiled with The Code Works' Q/C compiler", т.е. QCC (известный также как C80 http://retroarchive.org/cpm/lang/c80v31.zip ), а не GCC. gcc для Z80 нет.Цитата:
Сообщение от Sayman
Исходники uzi я в свое время посмотрел, но пока с ним не занимался.
нене, ты говорил именно про сорцы UZI...
вот ))Цитата:
а исходный Uzi, т.к. он существено проще, всех вкусностей Uzix (типа TCP/IP) в исходниках все равно нет
а сорцы UZIX2.0 лежали гдето на том же сайте вроде...не помню..где и UZIX1.0. ток толку нет от него изза привязки к МСХ. с другой стороны. код на Сях написан. можно просматреть что да как там...нужное оставить/переписать, а не нужное убрать. но тут вопрос в другом. что даст эта система? какой от неё прок? так. для галочки ток если, а практической пользы будет как от неоса...
Хм, ну я то знаю про что я говорил :) , т.к. исходники UZI у меня есть уже давно, они есть на многих CPM-файловых хранилищах. Может, в моей фразе не хватило запятых, что ее можно понять по-другому, но в любом случае не стоит такого внимания. :D Вот что я писал:Цитата:
Сообщение от Sayman
Из текста понятно что оба исходника я просматривал.Цитата:
Сообщение от Error404
А TCP/IP для UZIX действительно в исходниках нет, как нет в исходниках и UZIX 2.0, есть только бинарники (по крайней мере на sourceforge, которая сейчас является домашней страницей проекта). В исходниках там существуют только UZI и UZIX 1.0.
А какой толк? Ну, не знаю. Кому-то понравится многозадачность, кому-то совместимость с прочими *nix на уровне исходников, кому-то эмулятор cpm (ведь исходная cpm - однозадачная, а тут получается многозадачная). Кому-то ничего не понравится, потому что пользуется другой системой, которая написана на асме и поэтому запускает игры быстрее. :)
Теперь понял. Это круто. Только не для спекка имхо, слишком мало всего - памяти, скорости и т.д. И потом речь идёт о бинарно-совместимых с точки зрения системы/процессора или чего вообще??? Орион\корвет\специалист тоже на Z80 базируются???Цитата:
Сообщение от Error404
Значит мы думаем об одном но по разному :-)Цитата:
Сообщение от Error404
С такой точкой зрения соглашусь и даже поддержу, +1Цитата:
Сообщение от Error404
А ещё скорость винта медленнее самой медленной SIMM EDO DRAM.Цитата:
Сообщение от Sayman
Речь про механизм виртуализации вообще а не про то какие при этом сложности.
ну да, разве что у Спека с 16к памяти :) , а вообще, с каких пор СР/М стала не для Спека? Она прекрасно работает и на более убогих по быстродействию машинах с 8080 процом и изначально для них и делалась, а Z80 для СР/М - дык это просто роскошь :)Цитата:
Сообщение от GriV
ну тут знаеш, если сравнивать винты вообще, то никакая SIMM не сравниться с винтами зотябы UDMA4 или UDMA5, про сата 2 молчу вообще! если организовать страйпт массив, то пропускная способность увеличивается до 6гигабит. какая тебе нафиг симм?! если идёт речь про реализацию на спектруме, то поверь, винты быстрее будет прокачивать данные чем любая рушка или симм память. Если ты говорить о виртуализации, т.е. иными словами про банальный своп - файл, то реализовать можно и на флоп - это безспорно, но вопрос в другом, ты сам то после скольки минут взвоеш и начнёш материться от таких тормозов? )))Цитата:
А ещё скорость винта медленнее самой медленной SIMM EDO DRAM.
Речь про механизм виртуализации вообще а не про то какие при этом сложности.
поэтому, своп лучше всего распологать на винте, и на то есть минимум две причины:
1) это даёт больше скорости при обмене с файлом подкачки, посравнению с флопами и сд накопителями
2) благодоря более крупному объёму вмещаемой информации, чем на ЦД или ФДД, есть возможность реализовать поддержку большего количество "псевдо ОЗУ" путём дополнительной виртуализации. в данном случае, для спектрума можно быдл бы снять ограничение на метр или 4...хоть до 4гигов....сколько винт позволит. всё ровно всё будет храниться и крутиться на винте.
вот и я незнаю. что же нужно народу?! гуя, консоль, простота? что?!? зажрались, мне кажиться многие...Цитата:
А какой толк? Ну, не знаю.
Добавлено через 1 час 21 минуту
эт вртятли...с80 не имеет отношение к этой теме. с другой стороны, мож и я сам чего то не так делаю, но структура не для с80, он скорее подхожит к хайтех...Цитата:
т.е. QCC (известный также как C80
при этом ошибки и там и там...
Имхо бред, ибо скорость кеш винта-память считать неправильно, надо считать скорость непосредственного считывания с винтов а не пропускной способности интерфейсов... лукавите :v2_wink2:Цитата:
Сообщение от Sayman
какая лукавите, поработайте с файл-серверами, хотябы под винь32. страйпт в данном случае. это считай dual chanel. чётные данные идёт по каналу 0. а нечётные по каналу 1. при этом, оба канал используются по полной свое\их возможностей. поскольку в одноканальном режиме, пропускная способность в теории возможна до 3х гигабыит, то соответственно в паре до 6ти.Цитата:
Имхо бред, ибо скорость кеш винта-память считать неправильно, надо считать скорость непосредственного считывания с винтов а не пропускной способности интерфейсов... лукавите
напомню, что при работу памяти как dual (т.е. 128бит), алгоритм применяется тотже и пропускная способность увеличивается в двое. это всё проверянно годам и работает на многих предприятиях, где скорость работы с винтом является ключевой. сам лично делал подобные масскивы, проблем небыло. скорость работы реально ощутима по сравнению с одновинтовой схемой.
Ага. Кроме того, на компах, не оборудованных DMA (а это все клоны ZX и большинство отстальных 8-биток), использовать IDE приходится в режиме PIO (т.е. узкое место - процессор), что субъективно работает чуть быстрее дисковода. :)Цитата:
Сообщение от CHRV
Товарищу просто надо побольше тематической литературы читать. Лучшие винты дают скорость около 100 мб в сек (линейную!), на файлах будет меньше (потому и говорю что СИММ будет быстрее). Курим http://www.fcenter.ru/cgi-bin/sitema...cgi?urlid=5803 и делаем выводы. Для спекка нет механизма ДМА и УДМА соответственно, там всё через программную логику идёт с максимальной скоростью около 300 кб в секунду для турбы с развёрнытыми циклами чтения в сплошные команды INI, практические же реализации это 100 кб/сек и менее (курим тут http://zx.pk.ru/showthread.php?t=189...E%F1%F2%FC+HDD ). Для флоппика скорость 20 кб/сек для ISDOS разбиения, разница конечно есть (как будто кто-то спорит), но даже не в 10 раз (и ещё надо подумать где тут тормоза). Так что RTFM в Вашем случае приобретает особый смысл.
А насчёт объёма - если у Вас будет 48К памяти, в нагрузку получить дополнительно почти мегабайт я считаю не так уж плохо. Тут где то опрос был, у кого какие компы, метровыми монстрами там вроде не более 10% могут похвастаться...
И потом, опять RTFM - тут (пока ещё) нет многозадачности, потому дополнительная память будет использоваться не так как на мелкомягком оффтопе - с жутким пересвоппингом, а по мере необходимости.