Просмотр полной версии : Алан Кокс представил Unix-подобную ОС Fuzix, ядро которой потребляет около 40 Кб ОЗУ
Никого не смущает, что обработка прерывания сейчас занимает примерно 30% процессорного времени? Если забить ret по адресу 38h, система начинает работать гораздо шустрее :)
Никого не смущает, что обработка прерывания сейчас занимает примерно 30% процессорного времени? Если забить ret по адресу 38h, система начинает работать гораздо шустрее :)
Эмм, но ведь отвалятся клавиатура, переключение задач и сигналы?
Error404
28.11.2014, 16:09
Никого не смущает, что обработка прерывания сейчас занимает примерно 30% процессорного времени? Если забить ret по адресу 38h, система начинает работать гораздо шустрее :)
А что лежит по адресу 38h?
А что лежит по адресу 38h?
вектор маскируемого прерывания
Эмм, но ведь отвалятся клавиатура, переключение задач и сигналы?
Я к тому, что надо бы как-то оптимизировать это. Хотя бы клаву. Сделать процедуру опроса порта клавиатуры на асме (чтение 8 байт и сравнение с предыдущим состоянием), а если уж что-то изменилось, то запускать сишную процедуру опроса.
---------- Post added at 18:40 ---------- Previous post was at 18:35 ----------
У меня сложилось впечатление, что кто-то где-то портит случайные байты. По крайней мере я уже не первый раз замечаю изменение сегмента кода в процессе работы init. Отследить это у меня не получается, сегмент пересекается с сегментом данных ядра, простая ловушка на запись в память мало помогает.
да там ещё сырое всё как пиндрец
Да. Вот.
Инструкция:
1. Взять флешь и создать ДВА раздела.
- Раздел 1 основной - FAT32.
- Раздел 2 основной - Linux. Обязательно НЕ-FAT32!
2. Скопировать ядро и загрузчик на раздел 1 (fusix-boot.$C fuzix.bin)
3. Залить на раздел 2 ФС FUZIX. Например, если флешка - устройство /dev/sdb, то делаем это так:
sudo dd if=fuzix.img of=/dev/sdb2 bs=512
Все.
Далее втыкаем флешь во пентеву и запускаем fusix-boot.$C
Жмём:
bootdev: 0
login:root
ssh# printenv (это пример, печатает переменные окружения)
многие команды ещё не работают (типа ls)
Однако ж у меня не грузится. Пишет образ ядра не найден (файл fuzix.b). Старый загрузчик грузил без проблем.
ой. я не тот загрузчик залил. нужен fuzix-boot-sd
---------- Post added at 22:58 ---------- Previous post was at 22:27 ----------
Перезалил http://zx-pk.ru/showpost.php?p=757566&postcount=243
Я считаю, это просто издевательство :)
Рожицу я не добавлял, оно само. Это символ с кодом 01, который и пишется чаще всего по случайному адресу.
Перезалил http://zx-pk.ru/showpost.php?p=757566&postcount=243
Теперь не пускает:
Login: root
Login incorrect
Бывает, если случайно записываемый символ попадёт в процедуру разбора строки из passwd. Запусти заново, иногда этот символ попадает в некритичную область, тогда выглядит так, как будто всё работает.
мда. глюков там ещё мульён. у меня тоже иногда не пускает..
а ещё - не всегда читает корректно с флешки.
писать пока толком не пишет никак
А у меня вылазит хрень в аттрибутах, если во время скролла активно жать клаву. Пытаюсь побороть.
Even more interestingly, a 48K ZX spectrum plus period extras (given banking support being added to SDCC) would look something like this
0x0000-0x3FFF kernel on a 48-64K banked interface 2 cartridge ROM
0x4000-5AFF screen
0x5B00-7D00 kernel data/bank helpers
0x7D00-7FFF udata
0x8000-FFFF user space
which if my sums are right means that ignoring the "slightly" crap performance on microdrives you could (in theory) run a real v7 bourne shell on a Spectrum 48K with a microdrive for swap and one for the rootfs ;-)
отсюда - https://plus.google.com/+AlanCoxLinux/posts/MtXvM1WUDPE
Планы жесть, конечно :)
Ребята извращаются)
48к со свапом... ААААААААААААААААААААААААА ААААААААААААААААА!!!!!
Муторное это дело: либы пилить. Муторно потом и тестить, а надо.
Потому предлагаю пересобирать FUSIX по мере поступления переписанных функций - так можно оперативней выявлять ошибки (а они будут).
Eltaron, SfS, не поленитесь, парни!
Вот fputc, уменьшил на 114 байт (195 против 309).
/* z80 rewriting by Amixgris/RT 19-11-2014, Russia */
#include "stdio-l.h"
int fputc(int ch, FILE * fp) __naked
{ ch, fp;
__asm
pop af
pop de ; ch
pop bc ; fp
push bc
push de
push af
ld (2$),de ; save ch
ld hl,#0x000c ; fp->mode
call 3$
ld (1$),hl
and a,#0x40 ; & __MODE_READING ???
jr z,00102$
push bc
push bc
call _fflush
pop af
pop bc
ld a,h
or a,l
jr z,00102$
;fputc.c:10: return EOF;
00152$:
ld hl,#0xFFFF
ret
00102$:
ld a,h
and a,#0x03
jr NZ,00152$ ; lower byte <> 0
ld a,l
and a,#0x020
jr NZ,00152$
00105$:
ex de,hl
ld hl,#0x0008 ; deflate = bufend
call 3$
ex de,hl
ld h,b ; deflate = bufpos
ld l,c
call 3$
or a,a
sbc hl,de
jr c,00107$
push bc
push bc
call _fflush
pop af
pop bc
ld a,h
or a,l
jr NZ,00152$
00107$:
;fputc.c:18: *(fp->bufpos++) = ch;
ld h,b ; deflate = bufpos
ld l,c
call 3$
ld a,(2$)
ld (hl),a ; write out ch
inc hl
ld d,b
ld e,c
ex de,hl
ld (hl),e
inc hl
ld (hl),d
;fputc.c:19: fp->mode |= __MODE_WRITING;
ld hl,#1$
set 7,(hl)
;fputc.c:22: if (((ch == '\n' && (v & _IOLBF)) || (v & _IONBF)) && fflush(fp))
inc hl
inc hl
ld a,#0x0a
cp (hl)
jr NZ,00112$
inc hl
xor a,a
cp (hl)
jr NZ,00112$
dec hl
dec hl
bit 0,(hl)
jr NZ,00113$
00112$:
bit 1,(hl)
jr Z,00110$
00113$:
push bc
push bc
call _fflush
pop af
pop bc
ld a,h
or a,l
jr NZ,00152$ ; exit eof
00110$:
;fputc.c:26: fp->bufwrite = fp->bufstart; /* Nope */
ld hl,#0x0004
add hl,bc
ex de,hl
;fputc.c:25: if (v & (__MODE_IOTRAN | _IOLBF | _IONBF))
ld a,(1$)
and a, #0x03
jr Z,00115$
ld hl,#0x0006
jr 00116$
00115$:
;fputc.c:28: fp->bufwrite = fp->bufend; /* Yup */
ld hl,#0x0008
00116$:
;fputc.c:30: return (unsigned char) ch;
add hl, bc
ldi
ldi
ld hl,(2$)
ld h,#0x00
ret
1$: .dw 0
2$: .dw 0
; in: hl = struct member deflate
; de = struct base
; out: hl = member content
3$: add hl,bc
ld a,(hl)
inc hl
ld h,(hl)
ld l,a
ret
__endasm;
}
Муторное это дело: либы пилить. Муторно потом и тестить, а надо.
Потому предлагаю пересобирать FUSIX по мере поступления переписанных функций - так можно оперативней выявлять ошибки (а они будут).
Eltaron, SfS, не поленитесь, парни!
Спасибо. Но я через пару дней улетаю в командировку на неделю-полторы. Так что выпаду на это время. Сейчас весь в погдотовке к командироке.
Но я через пару дней улетаю в командировку на неделю-полторы. Так что выпаду на это время. Сейчас весь в погдотовке к командироке.
Печаль :(
Печаль :(
Можешь зайти сюда.
https://github.com/salextpuru/FUZIX
Склонировать всё. И сам добавить что надо. Пропатчены либы для того чтобы с long-long работать и SDCC-3.4.0
Чё печалиться, когда можно просто самому попробовать? :)
---------- Post added at 21:23 ---------- Previous post was at 19:44 ----------
Eltaron, а утебя чтение-запись с диска не глючат? Не знаю - то ли драйвер кривоват то ли что.
Загружается шелл через раз. Иногда почемуто пишет "login incorrect".
или это может драйвер tty?
Загружается шелл через раз. Иногда почемуто пишет "login incorrect".
Кажется я нашёл, почему. В библиотеке crt.s весьма странно запускает процедуру main. Нафига подменять адрес возврата, да ещё выше аргументов - непонятно. Я сделал стандартно:
pop hl ; environ
ld (_environ), hl
call _main
jp _exit
Тут кстати видно, что из стека достаётся адрес переменных среды, однако в syscall_exec.c для нового процесса в стек кладётся только argc,argv. Я добавил ещё и их:
// Shove argc and the address of argv just below envp
uputw((uint16_t) nargv, nenvp - 1);
uputw((uint16_t) argc, nenvp - 2);
uputw((uint16_t) nenvp, nenvp - 3);
// Set stack pointer for the program
udata.u_isp = nenvp - 3;
После этих изменений логин у меня работает как и задумывалось.
---------- Post added at 20:41 ---------- Previous post was at 20:38 ----------
Вот только рожица всё ещё появляется :) А если не появляется - всё опять рушится...
---------- Post added at 21:13 ---------- Previous post was at 20:41 ----------
Можно и не менять syscall_exec.c, только адрес переменных вот так считать:
ld hl, #4 ; environ
add hl,sp
ld (_environ), hl
call _main
jp _exit
Спасибо. А ты на гитхабе есть? может закоммитишь это все туда?
На гитхаб я пока не пойду :)
---------- Post added at 21:43 ---------- Previous post was at 21:42 ----------
Вот интересно, в библиотеке есть putenv.c и setenv.c, обе хранят в статической переменной (каждая в своей) предыдущий выделенный блок памяти. И как это работает?
[/COLOR]Можно и не менять syscall_exec.c, только адрес переменных вот так считать:
ld hl, #4 ; environ
add hl,sp
ld (_environ), hl
call _main
jp _exit
у меня этот вариант и есть. хренатотам.. через раз пускается(
---------- Post added at 22:57 ---------- Previous post was at 22:55 ----------
кстати, третьим параметром в main() в твоём варианте envp не передать..
---------- Post added at 23:01 ---------- Previous post was at 22:57 ----------
лучше так:
ld hl, #6
add hl, sp
ld (_environ), hl
ld hl, #_exit ; return vector
push hl
jp _main ; go
тогда main( int argc, char* argv[], env** env); можно писать.
---------- Post added at 23:44 ---------- Previous post was at 23:01 ----------
если у тебя всё работает и не глючит - дай исходники, коли не жалко. я просто сравню какие файлы у меня менялись. и окончательно решу - где собака зарыта.
Загружается шелл через раз. Иногда почемуто пишет "login incorrect".
или это может драйвер tty?
У меня всё-превсё глючит. Login incorrect даже чаще, чем correct. Пока не нашел из-за чего. Попробую фикс b2m.
лучше так:
Не взлетит. В environ попадут не те данные.
И потом, что за хрень с адресом возврата, чем тебе не нравится call _main / jp _exit?
Никак не могу поймать, кто пишет 01 по случайному адресу. Проблема с login-ом чаще всего из-за этого.
---------- Post added at 00:23 ---------- Previous post was at 00:17 ----------
Я думал, это из-за неправильной environ, но сейчас там правильный адрес, но всё равно глючит.
Кстати, putenv не дублирует входящую строку, эта процедура лишь накапливает адреса, смысла передавать туда локальный buf нет никакого.
---------- Post added at 00:33 ---------- Previous post was at 00:23 ----------
Ого, поставил бряк на начало программы, и записал в файл, что загрузилось. Сравнил с оригинальным init - 7 байт забиты числом 01! Стоят достаточно далеко друг от друга. Т.е. загрузка файла глючит! Понятно теперь, почему иногда рожица выскакивает в сообщении из issue :)
---------- Post added at 00:39 ---------- Previous post was at 00:33 ----------
Отключил прерывания - работает идеально. Надо копать прерывания в момент загрузки файла.
---------- Post added at 00:41 ---------- Previous post was at 00:39 ----------
кстати, третьим параметром в main() в твоём варианте envp не передать..
Нахрена козе баян. envp сохраняется во вполне доступной статической переменной environ.
У меня всё-превсё глючит. Login incorrect даже чаще, чем correct. Пока не нашел из-за чего. Попробую фикс b2m.
А. ну значит не я один страдалец:)
Я уж и так и этак - уж думал, что с железом что не то.
Ну ладно, надеюсь, что пока я неделю езжу - разберётесь, кто в память срёт.:v2_dizzy_roll:
Ну ладно, надеюсь, что пока я неделю езжу - разберётесь, кто в память срёт.:v2_dizzy_roll:
Кто, понятно - обработчик прерывания. Непонятно, каким образом это ему удаётся, что никто не видит :)
Я и раньше пробовал отключать прерывания, но всё равно глючило. Но это было из-за неправильного адреса переменных среды. А теперь, если прерывания отключить, то загруженный init в точности совпадает с оригиналом.
Кто, понятно - обработчик прерывания. Непонятно, каким образом это ему удаётся, что никто не видит :)
Я и раньше пробовал отключать прерывания, но всё равно глючило. Но это было из-за неправильного адреса переменных среды. А теперь, если прерывания отключить, то загруженный init в точности совпадает с оригиналом.
А может всё дело гдето в районе freebuf() bfree() ? ну там места не хватает гдето для буфера - и он косячит?
Кто, понятно - обработчик прерывания. Непонятно, каким образом это ему удаётся, что никто не видит :)
Я и раньше пробовал отключать прерывания, но всё равно глючило. Но это было из-за неправильного адреса переменных среды. А теперь, если прерывания отключить, то загруженный init в точности совпадает с оригиналом.
Да, спасибо за наводку, разобрался.
Глючат функции переключения банок - map_*. В паре мест там есть вероятность, что если в процессе работы произойдет прерывание, то предыдущее (временно сохраненное) значение аккумулятора пропадет. А т.к. эти функции дергаются кучу раз в цикле, то вероятность крайне велика.
Можно добавить DI везде в начале всех map_*. А можно более радикально (http://github.com/atsidaev/FUZIX/commit/22e5c7a93fa76c164600f3530c9d5269648e050b) - я переписал всё обратно на использование стека. Делал на переменных с тем, чтобы однажды перекинуть UDATA в банкуемую область, но ну нафиг, хоть бы сначала то, что есть, отладить :)
Сейчас логин всегда проходит и шелл всегда стартует. Но при попытке что-нибудь запустить всё гарантированно виснет. Надо дальше ковырять.
Кажется я понял, как всё глючит.
Глюк происходит внутри цикла __uput. В теории, прерывания в этот момент должны быть запрещены, но switch_bank подло разрешает их перед возвратом. В итоге, если прерывания возникает между ld (place_for_a),a в map_process_always и запрещением прерывания в switch_bank, то place_for_a портится несколько раз, и в конце концов вызовом map_restore. К этому моменту в регистре А находится флаг _kernel_flag, равный еденице.
Короче, надо switch_bank фиксить, как там в комментарии сказано.
---------- Post added at 15:30 ---------- Previous post was at 15:29 ----------
Опоздал :)
То есть надо вместо di вызывать irq_store=di()?
А вместо ei - irq_restore(irq_store)?
---------- Post added at 16:48 ---------- Previous post was at 16:44 ----------
Но если "прерывания всегда запрещены" - то зачем вообще их разрешать?
Но если "прерывания всегда запрещены" - то зачем вообще их разрешать?
Этот DI был фиксом к чему-то. Без него не работало. Ну а EI в пару к нему.
Сейчас, правда, есть подозрение, что вылечил я тогда только один симптом, а причина была эта же самая, что и сейчас.
глядя на функции map_kernel() других архитектур - я вообще там чтото не вижу поигрывания прерываниями.
глядя на функции map_kernel() других архитектур - я вообще там чтото не вижу поигрывания прерываниями.
На других архитектурах есть возможность узнать, какая банка включена в данный момент (нужно для map_store). У нас нет, и поэтому вывод в порт и сохранение в current_map надо делать в рамках одной "критической секции". Ну и пошло-поехало.
Но, повторюсь, сейчас, когда DI нет, но всё переделано на стек, те глюки, что были, не вернулись. Поэтому и кажется, что то, что тогда di/ei что-то починили - это было всего лишь совпадением.
Error404
01.12.2014, 14:59
На других архитектурах есть возможность узнать, какая банка включена в данный момент (нужно для map_store). У нас нет, и поэтому вывод в порт и сохранение в current_map надо делать в рамках одной "критической секции". Ну и пошло-поехало.
Я делаю так: у меня все переключаемые банки в самом теле страничек последовательно пронумерованы перед стартом ядра значением, соответствующим коду порта переключения страниц: в служебной области выше UZIXBASE кроме служебных процедур и структур типа GotoUnix, GotoExit, UDATA_STASH, еще есть байтовая ячейка с номером страницы. Когда мне надо прочитать состояние порта переключения страниц (аппаратно он только на запись), я читаю ту ячейку (позже старта никогда туда более не записывая). Соответственно, нет необходимости в лишнем DI/EI и работает на несколько тактов быстрее. :)
Но при попытке что-нибудь запустить всё гарантированно виснет. Надо дальше ковырять.
Дурацкая ошибка - https://github.com/atsidaev/FUZIX/commit/eddc1831b314e5415f2e79d0fa3c658c0a5665bd, починил. Все программы с SfS-овского образа стартуют, никаких багов в работе не замечено. Медленно только всё.
Дурацкая ошибка - https://github.com/atsidaev/FUZIX/commit/eddc1831b314e5415f2e79d0fa3c658c0a5665bd, починил. Все программы с SfS-овского образа стартуют, никаких багов в работе не замечено. Медленно только всё.
Спасибо огромное. Засунул в пентевную архитектуру стековый вариант переключалки - и ура! работать стало стабильно.
На реальной пентеве даже копирование проходит и симлинки создаются!
На реальной пентеве даже копирование проходит и симлинки создаются!
Добавил в тырдосный драйвер от b2m запись. ln проходит, rm проходит. cp и touch валятся.
http://dl.dropboxusercontent.com/u/20289147/zx/fuzix_5.png
bootdev: 0
login:root
ssh# printenv (это пример, печатает переменные окружения)
А в какой ветке у тебя этот правленный шелл лежит? Хочу пересобрать юзерспейс с оптимизированной либой.
А в какой ветке у тебя этот правленный шелл лежит? Хочу пересобрать юзерспейс с оптимизированной либой.
А его вообще в репозиториях нет. потому как просто кромсанул - удалил чуть не половину...
кстати, ls тоже не собирается в 16 К
Прицепил сюда.
Отлаживал урезанный вариант ls, нашёл неслабую ошибку в библиотеке. Файл readdir.c должен оканчиваться так:
strncpy(buf->d_name, (char *) direntry.d_name, len - 2);
buf->d_name[len - 2] = 0;
return buf;
Раньше обнулялся байт по смещению len-1, в результате портилась цепочка свободной памяти.
Прикладываю также свои варианты ssh и ls. Шелл на пару Кб больше, чем у SfS, зато функциональность не пострадала. В ls закомментировал сортировку и вывод времени.
Отлаживал урезанный вариант ls, нашёл неслабую ошибку в библиотеке. Файл readdir.c должен оканчиваться так:
Ого, классная бага! Запушил Алану http://github.com/EtchedPixels/FUZIX/pull/22
Если честно, я бы вместо len-2 поставил константу MAXNAMLEN - и быстрее, и надёжнее. Мало ли что вернёт система :) Сейчас она всегда возвращает 32.
Глядя на то, как медленно и печально грузится ls, мне пришла в голову мысль, что основную часть библиотеки libc нужно бы разместить в ПЗУ. Варианта, естесственно, три:
1. вместо BASIC48
2. вместо TRDOS
3. вместо RESET SERVICE
В первом варианте теряем возможность запускать игрушки, во втором - запускать дисковые игрушки, третий вроде подходит, но нужно будет обращаться через 3Dxx, к тому-же будут открыты порты BDI.
Что думает по этому поводу уважаемый Eltaron? :)
Что думает по этому поводу уважаемый Eltaron? :)
Я ничего не знаю про RESET SERVICE, но идея разделяемой либы, конечно, хорошая. С точки зрения маппинга будут проблемы - нужно сохранять/восстанавливать не только страницу ОЗУ, но и ПЗУ. Но это решаемо.
У меня была другая идея - выделить под либу одну из страниц ОЗУ. Но тут не только с маппингом пришлось бы попрыгать, но и с вызовом библиотечных функций. Новый RST городить, или ещё какую-нибудь точку входа ниже #C000.
Я ничего не знаю про RESET SERVICE
Это когда ставят 256Кб 64Кб ПЗУ, в которой и BASIC48, и BASIC128, и TRDOS в одной м/с. Насколько я понял, там остаётся ещё одна свободная страница, которая включается после сброса, если BDI настроен на автоматическое включение TRDOS после сброса.
С точки зрения маппинга будут проблемы - нужно сохранять/восстанавливать не только страницу ОЗУ, но и ПЗУ.
Там всё просто: для ядра - ядро, для режима пользователя - либа. RST, конечно, надо в либе реализовать, также как и обработку прерывания в режиме пользователя.
У меня была другая идея - выделить под либу одну из страниц ОЗУ.
А как быть с адресами данных, которые по любому в другой странице ОЗУ вместе с программой?
У меня была аналогичная идея, но я думал освободить непереключаемое ОЗУ для libc и других разделяемых библиотек, практически полностью перенеся ядро в переключаемые страницы. Много занимают буфера, но перенеся их в другие страницы мы усложняем загрузку файлов в область программы. А если, например, код ядра и буфера будут в разных страницах, то тут могут другие сложности возникнуть.
Вобщем libc в ПЗУ - наиболее простое решение.
solegstar
08.12.2014, 16:15
Это когда ставят 256Кб ПЗУ
ну ПЗУ ставят на самом деле 64кб (27С512), 4 страницы по 16кб. первые 16 кб или свободны или используются под свои нужды - командеры, менюшки, либы как в вашем случае, вторая страница используется под ТРДОС, третьи 16кб используется под бейсик 128, который часто меняют опять же на командеры или какой-то альтернативный менюшке софт, и последняя 4я страница это прошивка бейсик 48кб для 128 машин, его менять само собой нельзя. т.е. если разобраться в вашем распоряжении могут быть две страницы по 16 кб - это 1я и 3я (считаем с 1й).
ну ПЗУ ставят на самом деле 64кб (27С512)
Ой, пардон, разрядность зашкалила :)
---------- Post added at 22:34 ---------- Previous post was at 22:30 ----------
Ту страницу, что под бейсик 128, мы уже используем как часть ядра. Остаётся самая первая страница (её обычно вроде reset service называют?)
Я, конечно, не отказываюсь от идеи переписать либы на асме, но всё-таки. Может быть попробовать скомпилить FUZIX IAR`ом?
Кстати, кто-нибудь объяснит, где взять правильный stdint.h и почему его нет в дистрибутиве?
Я, конечно, не отказываюсь от идеи переписать либы на асме, но всё-таки. Может быть попробовать скомпилить FUZIX IAR`ом?
Муторно это, всю инфраструктуру переделывать надо. И все .s фиксить.
Кстати, кто-нибудь объяснит, где взять правильный stdint.h и почему его нет в дистрибутиве?
Это часть sdcc. /opt/sdcc/include
Это часть sdcc. /opt/sdcc/include
Досадно. В IAR такого файла нет.
Error404
10.12.2014, 18:15
Сколько памяти под стек нужно ядру? Хотя бы порядок - 100 байт, 256, килобайт... сколько?
Можете поглядеть на работающей системе (в эмуляторе к примеру)?
Сколько памяти под стек нужно ядру? Хотя бы порядок - 100 байт, 256, килобайт... сколько?
Можете поглядеть на работающей системе (в эмуляторе к примеру)?
За пару минут работы самое большее, что отхапывало - 160 байт.
Алан запилил микродрайв!
https://github.com/EtchedPixels/FUZIX/commit/1da9b239cc3d5fa1a867e44408c519c8f6c75330
Алан запилил микродрайв!
https://github.com/EtchedPixels/FUZIX/commit/1da9b239cc3d5fa1a867e44408c519c8f6c75330
А с +2 микродрайв несовместим.:(
Error404
11.12.2014, 22:32
Алан запилил микродрайв!
https://github.com/EtchedPixels/FUZIX/commit/1da9b239cc3d5fa1a867e44408c519c8f6c75330
На очереди карт-пунчер и карт-ридер? :)
Тогда как народ страдает без TCP/IP и FAT!
ОФФТОП) Еду заватра домой. Надеюсь включусь в доработки через несколько деньков
Робяты, а что тут тишина? ) никто не пилит FUZIX?)
Робяты, а что тут тишина? ) никто не пилит FUZIX?)
Алан пилит :)
Лично у меня всяческие отчеты и прочая декабрьская рутина, не до фузихов.
Алан пилит :)
Лично у меня всяческие отчеты и прочая декабрьская рутина, не до фузихов.
Анал огично)
приехал, буду ещё неделю мудохаться минимум. но есть желание продолжить фузикс.
Error404
07.01.2015, 19:02
Алан запилил микродрайв!
https://github.com/EtchedPixels/FUZIX/commit/1da9b239cc3d5fa1a867e44408c519c8f6c75330
Чего там у Алана, какие новости? Кто-нибудь мониторил?
Шибко интересно про TCP/IP.
Как-то на евоном CVS собирать инфу по крохам из комментов к правкам модулей - весьма неудобно.
Надеемся и верим, что после праздников работы по теме "ФУЗИКС" возобновятся с новой силой!:)
Чего там у Алана, какие новости? Кто-нибудь мониторил?
Шибко интересно про TCP/IP.
TCP ещё нету. Запилили поддержку Z180, счас там чел, который socz80 разработал, коммитит активно.
Error404
17.01.2015, 02:37
Поковырялся немного в коммитах ихнего CVS, составить представление чего там творится почти не возможно: коммитится много всякой мелочевки, комментится скудно. Нужны дайджесты! Чтобы не пропустить что-то интересное.
Обратил внимание, что у FUZIX 62 функции ядра, тогда как у UZIX v1.0, более развитого чем UZI который по сути и есть FUZIX, их только 40 (и что характерно - на все хватает). Чего там добавлено при более чем вдвое большем количестве функций? У Юзикс такие функции:
GBL char *disp_names[] = {
/*00*/ "access",
"alarm",
"brk",
"chdir",
"chmod",
/*05*/ "chown",
"close",
"getset",
"dup",
"dup2",
/*10*/ "execve",
"exit",
"fork",
"fstat",
"getfsys",
/*15*/ "ioctl",
"kill",
"link",
"mknod",
"mount",
/*20*/ "open",
"pause",
"pipe",
"read",
"sbrk",
/*25*/ "seek",
"signal",
"stat",
"stime",
"sync",
/*30*/ "time",
"times",
"umount",
"unlink",
"utime",
/*35*/ "waitpid",
"write",
"reboot",
"symlink",
/*39*/ "chroot"
};
Error404
23.01.2015, 10:08
В отпусках все что ли?
В отпусках все что ли?
Все во флейме :)
ну на работе я ОСью заниматься не могу, а пару постов во флейм - завсегда)
На сегу мегадрайв ещё не компилировали эту ОС ?
Или 68k в пролёте ?
NovaStorm
24.01.2015, 22:12
На 68k можно и что-то более полноценное взгромоздить. Благо адресное пространство позволяет.
На 68k можно и что-то более полноценное взгромоздить.
Можно то оно можно. Но вряд ли кто-нибудь займётся подобным.
Благо адресное пространство позволяет.
Только конкретно в мегадрайве это адресное пространство представляет из себя ПЗУ.
оперативки же всего 128 кб.
Error404
24.01.2015, 23:39
оперативки же всего 128 кб.
Тогда ой. Contiki, в лучшем случае.
Ну или какие-нибудь носители с быстрым обменом через DMA использовать, но все равно это будет медленно ИМХО.
оперативки же всего 128 кб.
А ещё есть статическое ОЗУ в картридже на 32 кб.
Сега-программист gasega использует это ОЗУ, только на 64кб в своей техно-деме mode7. Но на 64кб оно есть в MegaEverdrive. У меня просто everdrive, там только 32 кб, и поэтому текстуры разбиты полосками.
(http://www.sega-16.com/forum/showthread.php?29069-Mode-7-demo-for-Genesis-MD)
---------- Post added at 01:41 ---------- Previous post was at 01:38 ----------
Тогда ой. Contiki, в лучшем случае.
Видал в архиве public domain (где выложены все-все-все любительские поделки на мд) демку типа POST-загрузка. Инициализация железа. Прикольно смотрелось.
Как прекрасен мир, когда из всего написанного понимаешь только связующие слова )))Полностью согласен.
Хоть кто-нибудь пару-тройку картинок разместите, что это за "зверь", как выглядит это дело на экране.
Error404
14.02.2015, 00:37
Помойка исходников, из которых можно попробовать надергать что-то полезное для *UZIX:
http://ftp.sunet.se/pub/usenet/ftp.uu.net/comp.sources.unix/index
http://ftp.sunet.se/pub/usenet/ftp.uu.net/comp.sources.unix/
Понятно, что их в принципе существенно больше чем одна, но мне понравилась эта: престарелые исходники (что для нас немаловажно), есть индекс по архивам.
Полностью согласен.
Хоть кто-нибудь пару-тройку картинок разместите, что это за "зверь", как выглядит это дело на экране.
Гы гы гы! Для тех кто мало знает про историю компов, скажу так - эта OS (и не токо эта но и cp/m unix rsx11 rt11 и т.д.) БЕЗ СТАНДАРТНОГО API для графики. А значит "показывать" особо нечего (в смысле ААА на youtube обзор не выложит так как не будет смотреться эффектно). Стандартное програмное обеспечение этой OS работает с телетайпом типа как - Teletype Model 33.
Стандартное програмное обеспечение этой OS работает с телетайпом типа как - Teletype Model 33.
Не ну, эмулятор tty я всё ж реализовал. Вообще, тут в теме все есть, и скриншоты, и даже фото экрана реальной Эвы.
Error404
24.02.2015, 23:39
Помойка исходников, из которых можно попробовать надергать что-то полезное для *UZIX:
http://ftp.sunet.se/pub/usenet/ftp.uu.net/comp.sources.unix/index
http://ftp.sunet.se/pub/usenet/ftp.uu.net/comp.sources.unix/
Понятно, что их в принципе существенно больше чем одна, но мне понравилась эта: престарелые исходники (что для нас немаловажно), есть индекс по архивам.
Еще архивы исходников ранних версий *NIX:
http://minnie.tuhs.org/cgi-bin/utree.pl
Нам будет близок Seventh Edition Unix, КМК
Гы гы гы! Для тех кто мало знает про историю компов, скажу так - эта OS (и не токо эта но и cp/m unix rsx11 rt11 и т.д.) БЕЗ СТАНДАРТНОГО API для графики. А значит "показывать" особо нечего (в смысле ААА на youtube обзор не выложит так как не будет смотреться эффектно). Стандартное програмное обеспечение этой OS работает с телетайпом типа как - Teletype Model 33.
Открою тайну - в UNIX вообще нет "СТАНДАРТНОГО API для графики" :)
Есть абстракция видеодрайвера - фреймбуффер и есть консоли-терминалы.
Графические приложения либо работают через фреймбуфер, либо, чаще - через отдельный графический X-сервер.
Так что с этой стороны как раз всё нормально.
Error404
07.04.2015, 11:41
Что, The End ?
Проблема большая, что под программу пользователя - 16К. Максимум на 128 спеке
Разделяемых библиотек - тоже не предусмотрено.
Можно сделать всё это под пентеву - но тогда это будет "пентева-только" система.
Для 128 спека надо что-то иное выдумывать.
Да и контекст очень медленно щёлкается.
Ну или делать только для пентевы свою ось. Но тогда надо механизм запуска спекопрок продумывать.
Error404
09.04.2015, 21:42
Проблема большая, что под программу пользователя - 16К. Максимум на 128 спеке
Разделяемых библиотек - тоже не предусмотрено.
Можно сделать всё это под пентеву - но тогда это будет "пентева-только" система.
Для 128 спека надо что-то иное выдумывать.
Да и контекст очень медленно щёлкается.
Ну или делать только для пентевы свою ось. Но тогда надо механизм запуска спекопрок продумывать.
Контекст будет переключаться быстро, если переключать целыми страницами по 64к, минимизировав межстраничные копирования. Есть куча клонов с расширенным ОЗУ, надо только добавить диспетчер по 64к (а во многих, где 4 диспетчера по 16к, и добавлять ничего не надо, просто будет 4 команды включения страницы 16+16+16+16 вместо одной 64). Когда это нас стала пугать необходимость доработки? Если бы мне в, скажем, 96-м году сказали "вот тебе Юникс, но надо 3 микросхемки добавить", эти микросхемки были бы добавлены в тот же день. В конце концов, тут паяльщиков 50 человек на каждого программиста, ваще проблемы не вижу.
запилить этот юзикс на спринтера, чтоли?! только, какая практическая от этого польза?! сомнительное это нынче удовольствие...
AHTuXPuCT
10.04.2015, 07:14
Sayman, на феню запили ;)
AHTuXPuCT, не, фени нету и не хочу "её".
Error404
10.04.2015, 09:58
запилить этот юзикс на спринтера, чтоли?! только, какая практическая от этого польза?! сомнительное это нынче удовольствие...
Вообще-то я думал ты как раз за этим с С-компилерами связался. :)
---------- Post added at 09:58 ---------- Previous post was at 09:56 ----------
AHTuXPuCT, не, фени нету и не хочу "её".
А напрасно. У нас тут есть живой автор, он бы диспетчер с большим окном и впилил бы.
Вообще-то я думал ты как раз за этим с С-компилерами связался.
совершенно нет. Не только-лишь юзикс можно на си наваять))
А напрасно. У нас тут есть живой автор, он бы диспетчер с большим окном и впилил бы.
феникс это обычный скорпоКай. без всяких излишеств. не интересная для меня железка.
Error404
10.04.2015, 12:15
феникс это обычный скорпоКай. без всяких излишеств. не интересная для меня железка.
"Искаропки" там только стандартный диспетчер по 16к? А какие вообще клоны умеют оперировать большими страницами памяти?
Error404, если ты про включение страниц во все 4 окна проца, тогда: атм, evo, спринтер. про феникса не знаю, может тоже умеет. может ещё есть какие-то.
AHTuXPuCT
10.04.2015, 13:31
Sayman, еще эва есть :)
... Есть куча клонов с расширенным ОЗУ, надо только добавить диспетчер по 64к (а во многих, где 4 диспетчера по 16к, и добавлять ничего не надо, просто будет 4 команды включения страницы 16+16+16+16 вместо одной 64).
64k? а какой толк от него будет? прийдется пересылать блоки между страницами только через регистры процессора (которых галяк), ну или через тормознутый i/o... (и тогда надо будет иметь копию кода для этого i/o в каждой странице) или тогда надо будет лепить какой-то еще memory-memory "копировщик" кроме Z80 на шину...
Error404
10.04.2015, 17:19
64k? а какой толк от него будет? прийдется пересылать блоки между страницами только через регистры процессора (которых галяк), ну или через тормознутый i/o... (и тогда надо будет иметь копию кода для этого i/o в каждой странице) или тогда надо будет лепить какой-то еще memory-memory "копировщик" кроме Z80 на шину...
64к это условно.
На Орионе например переключается только 60к (а верхние 4к "склеенные" для всех страниц). Такая же модель памяти была исходной у Кокса при написании FUZIX. Достаточно удобно получается. Учитывая, что Юзиксу надо в общей памяти максимум 1к ("общей памяти"), то окно может быть и до 63кб размером. При этом каждое переключение контекста - это ldir примерно 2х400 байт ОЗУ + сохранение/восстановление регистров ЦПУ. Несравнимо с ldir Nх16к (в случае если делать процессы больше 16к при окне диспетчера 16к).
Но даже если переключать 3 окна по 16к - нижние 48k (а верхние 16к - "склеенные", в них кстати можно разместить непереключаемые общие для всех процессов бинари, тот же libc частично, или эмулятор CP/M), то 48к на процесс - это и то очень прилично.
Удобство в том, что пофиг сколько у тебя окон и какой размер страниц. Например, в моей реализации с 60-к страницами без перекомпиляции прекрасно работают бинарники однатысяча девятьсот мохнатого года от 32к-страничного Юзикса. Т.е. у нас будет кросплатформенность (точнее крос-клоновость) "вопреки всему" :)
Удобство в том, что пофиг сколько у тебя окон и какой размер страниц. Например, в моей реализации с 60-к страницами без перекомпиляции прекрасно работают бинарники однатысяча девятьсот мохнатого года от 32к-страничного Юзикса. Т.е. у нас будет кросплатформенность (точнее крос-клоновость) "вопреки всему" :)
А ну так это другое совсем, это "максимальное адресуемое пространство для процесса", ясное дело чем жирнее оно тем проще писать прогу (уже обсосали 100 раз, факт что большенство алгоритмов в литературе и компиляторов в жизни не учитывают лимитов адресного пространства).
К стати тут уже движутся работы в направлении прикручивания link-ера поддерживающего overlays. https://github.com/EtchedPixels/FUZIX/blob/master/Kernel/doc/SDCCBanking
CityAceE
20.05.2015, 14:44
Какой-нибудь прогресс?
Какой-нибудь прогресс?
Да никакой, уже более 30 лет :)
Запуск на Спектруме мультизадачной операционной системы изначально не возможен без аппаратных доработок и замены процессора на более быстрый. Ну не побежит дедушка Z80 так, как к примеру на FPGA:
http://zx-pk.ru/attachment.php?attachmentid=50078&d=1416954953
Т.к. начало поддержано не было (ссылка (http://zx-pk.ru/showpost.php?p=757093&postcount=118)) дальнейшая работа над проектом была свернута. Так, что не видать здесь мультизадачной ОС еще н-нацать лет :biggrin:
Какой-нибудь прогресс?
Пилю printf на асме. Основная проблема, из-за которой встала работа - катастрофическая нехватка памяти. А львиная доля её приходится на printf() и scanf(). Надеюсь, за счет использования асма и упрощения формата хотя бы килобайта 4 выиграть. Думаю, это позволит продолжить работу над портированием, если "портаторы" не потеряют интерес к тому времени.
А львиная доля её приходится на printf() и scanf().
всегда удивлялся нафига такая сложная функция в ядре системы??? неужели обычного putchar() getchar() было им мало для реализации требуемого функционала?
NovaStorm
23.05.2015, 23:22
А он так или иначе нужен ведь, почему бы и в ядре не попользоваться тогда?
Error404
24.05.2015, 01:59
Да никакой, уже более 30 лет :)
Запуск на Спектруме мультизадачной операционной системы изначально не возможен без аппаратных доработок и замены процессора на более быстрый. Ну не побежит дедушка Z80 так, как к примеру на FPGA:
:
на 7 МГц вполне нормально работает - сужу по uzix, они почти не отличаются с эхотагом, юзикс даже понавороченнее будет. архитектуру только пишите так, чтобы при переключении контекстов был минимум пересылок по памяти
А он так или иначе нужен ведь, почему бы и в ядре не попользоваться тогда?
Как по мне дак совсем не обязательно такому куску как ЯДРО, уметь печатать и форматировать текст так круто как может printf() вполне себе элементарного get/put хватало бы в какую-нибудь виртуальную "консоль", а тут выходит вот такой пример (утрированный), есть грубо говоря 3 куска кода занимающих всю память, 1-й ядро, 2-й printf(), 3-й прога LS например... они как не крути всю память зажрали, если printf() часть ядра то ясное дело что для LS нет маневра, даже тогда если LS решит токо половину printf-a использовать... вот и вся логика.
А вообще со времен прочтения про modula2 для pdp11 пришло понимание того что надо "уметь" разбивать прогу любой длинны и сложности на куски размером с 1 страницу (для zx это 16kB), тогда можно будет имея пачку свободных страничек + какой-то рабочий буфер выполнять и код ядра и код задач несмотря на ограниченное адресное пространство.
---------- Post added at 05:45 ---------- Previous post was at 05:16 ----------
на 7 МГц вполне нормально работает - сужу по uzix, они почти не отличаются с эхотагом, юзикс даже понавороченнее будет. архитектуру только пишите так, чтобы при переключении контекстов был минимум пересылок по памяти
Я так понимаю что "некоторые" варианты pdp11, (такие как тот же f11 применявшийся в pdp11/23) работают в той же "скоростной категории" что и z80, просто потому что это все те же 5мкм и соответственно примерно равные частоты, а битность на скорость влияет не так сильно как частота и кэши. Так вот многозадачность там работает, в том плане что может сидеть там паралельно человек 5 и набивать текст ed-ом и потом, компилировать его и играть там в rogue... Про графику забудьте, даже в самых простых динамических играх типа manic miner 90% скорости процессора потраченно на графику, так что надо вешать к спектруму еще один Z80 + память (шото типа general sound) и пускать тогда уже unix на нем, такая идея обкатанна на acon bbc b с его tube интерфейсом и множеством видов "second processor"-ов.
Между тем, в мире появился первый человек, получающий за разработку FUZIX зарплату
https://github.com/EtchedPixels/FUZIX/issues/191#issuecomment-105659998
А у меня появилось стойкое ощущение, что в ZX128 оно больше не влазит.
Переписывание процедур на асме у меня продвигается ОЧЕНЬ медленно. Но, думаю, в настоящее время, с появлением SDCC v.3.5 имеет смысл не ждать пока я что-нибудь "рожу", а попробовать собрать ОСь новым компилятором, плотность кода СУЩЕСТВЕННО выросла по сравнению с предыдущей версии.
Собрал на досуге последнюю версию. Алан там наворотил, и теперь изменена вся схема памяти: во-первых, используется только ОЗУ, во-вторых, используется экран в 0xC000. То есть переключаемые страницы используются для всего подряд - и экран в них, и код ядра, и пользовательские программы. Всё это безобразие собирается только sdcc со специальными патчами для возможности кросс-банковых CALL-ов.
Затея достаточно интересная, конечно - и отлаживаться можно на любом эмуляторе (результат компиляции - z80/sna-файл), и в железе никаких изменений не требуется. Правда вот из-за этих новшеств драйвер бетадиска теперь не работает, и файловую систему не подсунуть.
Не прошло и года...
В общем, недавно вспомнил, что обещался printf на асме забацать. Спешу порадовать, что printf`у быть! :)
Собственно, автомат написан, но сегодня не выложу, ибо код ещё очень грязен, и не весь формат, какой хотел, реализован.
Это не сама printf, а служебная функция для её реализации. Её параметры: адрес п/п печати символа, адрес управляющей строки, адрес начала списка аргументов.
Думаю нужно обсудить, до какой степени упростить функцию.
Что поддержано на сегодня:
- Печать строк (%s), символов (%c), чисел десятичных (%d,%i,%u), шестнадцатиричных (%x,%X) и восьмеричных (%o).
- Размеры чисел от байта до лонга, т.е. спецификаторы "l" и "hh"
- Печать незначащих нулей в старших разрядах - флаг "0"
- Печать "+" перед положительным числом - флаг "+"
На остальные спецификаторы стоят заглушки.
Решил отказаться от обработки полей и выравнивания.
Пока длина кода составляет 844 байта.
Какие будут соображения?
Lethargeek
05.02.2016, 05:25
- Печать незначащих нулей в старших разрядах - флаг "0"
Решил отказаться от обработки полей и выравнивания.
так выравнивание почти то же самое, только выводить пробелы вместо нулей ??
так выравнивание почти то же самое, только выводить пробелы вместо нулей ??
Я думал, чтобы знать сколько надо отступить от левой границы поля, надо знать длину выводимого текста заранее, а для этого нужно сначала вывести текст в буфер, посчитав символы, а только потом уже в поток. Ради ускорения я пишу так, что всё сразу выводится в поток. Для чисел расчитать заранее ещё можно, а для строки - нет. Или я не правильно прочёл описание формата.
Lethargeek
05.02.2016, 15:53
надо знать длину выводимого текста заранее, а для этого нужно сначала вывести текст в буфер, посчитав символы,
зачем вывести? можно ведь заранее посчитать и длину видимого текста форматирующей строки, и каждого параметра по отдельности (числового или строкового - неважно)
всё заглохло? Очень странно, видел какую-то сборку под Эву (которую так и не смог запустить, увидел только мельком начало инициализаци и всё...), только так и не понял, почему не поддержан тектовый режим, 4 метра памяти и другие навороты? Опять таки, есть тс-конфа, но и она не поддержана.
всё заглохло? Очень странно, видел какую-то сборку под Эву (которую так и не смог запустить, увидел только мельком начало инициализаци и всё...), только так и не понял, почему не поддержан тектовый режим, 4 метра памяти и другие навороты? Опять таки, есть тс-конфа, но и она не поддержана.
Потому что нет особенного смысла поддерживать ОС, под которую нет софта, зато в ядре которой с периодичностью в месяц меняется ну просто всё.
Мы по быстрому убедились, что за пару недель можно неспешно портировать фузикс на zx (ну, в каком-то виде). Это знание теперь с нами и никуда не денется.
Мои патчи давно в апстриме и тоже никуда не денутся, Алан хоть на zx не упирает, но и поломанным несобирающимся тот тоже не лежит.
Вот будет реальная причина возобновить работу - TCP/IP стек с юникс сокетами, например - тогда будем посмотреть.
Error404
05.07.2016, 22:36
Вот будет реальная причина возобновить работу - TCP/IP стек с юникс сокетами, например - тогда будем посмотреть.
Подпишусь.
Пока что не было особо за что биться. Тоже жду что у них получится со стеком.
Подумал, если буду ждать, пока улучшу процедуру, то хрен знает, когда я её выложу. Поэтому выкладываю как есть. Опробована в приложениях для бризовского CLI2. Для использования в своих целях замените подпрограмму вывода символа "OUTCHR":
OUTCHR::
exx
bit 7,c ; charcounter > 127 ?
jr nz,OCHe
OUTCH: ld (de),a
inc de
inc c
OCHe: exx
ret
Сейчас процедура печатает в буфер, содержимое которого потом выводится средствами CLI2:
EXIT: exx
push bc
inc de
ex de,hl
ld (hl),#0 ; ставим 0 в конце сформированной строки.
exx
ld hl,#buffer
ld a,#0x0e
call 0x8003 ; CLI2 printString
Процедура полностью. Формат исходника - SDCC/sdasz80
unsigned int printfx(unsigned char* cmdstr,...) __naked
{cmdstr;
__asm
TheFlag .equ 1
TheNum .equ 2
TheSize .equ 3
TheType .equ 4
sz_l .equ 0
sz_hh .equ 1
sz_h .equ 2
sz_ll .equ 3
sz_j .equ 4
sz_z .equ 5
sz_t .equ 6
sz_L .equ 7
PRINTF::
LD (EXITT+1),SP
POP BC ; return addres
POP HL ; direct string addres
EXX
LD HL,#0
ADD HL,SP ; args ptr
LD BC,#0 ; C = char counter
LD DE,#buffer
EXX
PUSH HL
PUSH BC
MCICLE: PUSH HL
CALL RESET
POP HL
WCICLE: LD A,(HL)
OR A
JR Z,EXIT
CP #'%'
JR NZ,M3
inc hl
ld a,(hl)
cp #'%'
jr z,M3
M4: CALL ParseFormat
OR A
JR NZ,M1 ; что за спецификатор?
LD A,(HL) ; нераспознанный спецификатор печатается как обычный символ.
M3: CALL OUTCHR
INC HL
JR WCICLE
M1: INC HL
CP #TheType
JR Z,MCICLE
LD A,(HL)
JR M4
EXIT: exx
push bc
inc de
ex de,hl
ld (hl),#0
exx
ld hl,#buffer
ld a,#0x0e
call 0x8003
pop hl ; char counter
EXITT: LD SP,#0
RET
; parsing routines for PRINTF
ParseFormat::
; in: A = checking symbol.
PUSH HL
LD HL,#FlagL
LD D,H
LD E,L
LD BC,#5
CPIR
JR NZ,ChkNum ; found
DoFlags: LD BC,#FlagSbr
DO: OR A,A
SBC HL,DE
DEC HL
ADD HL,HL
ADD HL,BC
LD E,(HL)
INC HL
LD D,(HL)
EX DE,HL
JP (HL)
ChkNum: LD HL,#NumL
LD D,H
LD E,L
LD BC,#10
CPIR
JR NZ,ChkSize
LD C,A
LD A,#TheNum
RET
ChkSize:
LD HL,#SztpL
LD D,H
LD E,L
LD BC,#6
CPIR
JR NZ,#ChkType
LD BC,#SizeSbr
JR DO
ChkType:
LD HL,#TypeL
LD D,H
LD E,L
LD BC,#7; 19
CPIR
JR NZ,ChkPoint
DoType:
LD BC,#TypeSbr
JR DO
ChkPoint:
XOR A,A
DoPresn:
DoStar:
RET
; service subroutines for PRINTF
I2D:: LD C,#0
LD DE,#10000
CALL CNT
LD DE,#1000
CALL CNT
LD DE,#100
CALL CNT
LD DE,#10
CALL CNT
LD A,L
CALL OUTNUM
RET
CNT: XOR A,A
CNTL: OR A,A
SBC HL,DE
JR C,CNT1
INC A
JR CNTL
CNT1: ADD HL,DE
CALL OUTNUM
RET
;-----------------------
GETWORD::
GETPTR::
EXX
LD E,(HL)
INC HL
LD D,(HL)
INC HL
PUSH DE
EXX
POP DE
RET
;-----------------------
GETBYTE::
EXX
LD A,(HL)
INC HL
EXX
RET
OUTSTR::
LD A,(HL)
OR A
RET Z
CALL OUTCHR
INC HL
JR OUTSTR
OUTCHR::
exx
bit 7,c ; charcounter > 127 ?
jr nz,OCHe
OUTCH: ld (de),a
inc de
inc c
OCHe: exx
ret
OUTNUM::
PUSH HL
LD HL,#zero
OR A
JR Z,oNM1
SET 0,(HL)
JR oNM2
oNM1: BIT 0,(HL)
JR Z,oNMe
JR oNMo
oNM2: CP #0x0A
JR C,oNMo ; not HEX
BIT 2,(HL)
JR Z,oNM3 ; upper case HEX
ADD A,#32 ; lower case HEX
oNM3: ADD A,#7
oNMo: ADD A,#"0"
CALL OUTCHR
oNMe: POP HL
RET
RESET:: LD HL,#sizes
LD DE,#sizes+#1
LD BC,#12
LDIR
EX DE,HL
LD (HL),#6
RET
; обработка флагов
FlagSbr:
.dw doDefice
.dw doSign
.dw doSpc
.dw doOkto
.dw doZero
doDefice:
LD A,#TheFlag
LD (defice),A
POP HL
RET
doSign:
LD A,#1
LD (sign),A
LD A,#TheFlag
POP HL
RET
doSpc:
LD A,#TheFlag
LD (#space),A
POP HL
RET
doOkto:
LD A,#TheFlag
LD (#alter),A
POP HL
RET
doZero:
LD A,#TheFlag
LD (zero),A
POP HL
RET
SizeSbr:
.dw do_l
.dw do_h
.dw do_j
.dw do_z
.dw do_t
.dw do_L
do_l:
POP HL
INC HL
CP (HL)
JR NZ,do_l1
LD A,(sizes)
SET sz_ll,A
JR do_h1e
do_l1: DEC HL
LD A,(sizes)
SET sz_l,A
JR do_h1e
do_h:
POP HL
INC HL
CP (HL)
JR NZ,do_h1
LD A,(sizes)
SET sz_hh,A
JR do_h1e
do_h1: DEC HL
LD A,(sizes)
SET sz_h,A
do_h1e: LD (sizes),A
LD A,#TheSize
POP HL
RET
do_j:
LD A,(sizes)
SET sz_j,A
POP HL
JR do_h1e
do_z:
LD A,(sizes)
SET sz_z,A
JR do_h1e
do_t:
LD A,(sizes)
SET sz_t,A
JR do_h1e
do_L:
LD A,(sizes)
SET sz_L,A
JR do_h1e
TypeSbr:
.dw do_d
.dw do_d
.dw do_u
.dw do_x
.dw do_X
.dw do_c
.dw do_s
do_d:: CALL GETWORD
EX DE,HL
BIT 7,H
JR Z,do_dpl
LD DE,#0
EX DE,HL
OR A,A
SBC HL,DE
LD A,#'-'
CALL OUTCHR
JR do_d1
do_dpl:
LD A,(sign)
OR A,A
JR Z,do_d1
LD A,#'+'
CALL OUTCHR
do_d1: LD A,(zero)
LD B,A
CALL I2D
LD A,#TheType
POP HL
RET
do_u:: CALL GETWORD
EX DE,HL
JR do_d1
do_x:: LD A,(zero)
SET 2,A
LD (zero),A
do_X:: LD A,#0x30
CALL OUTCHR
LD A,#'x'
CALL OUTCHR
CALL GETWORD
LD A,(sizes)
BIT sz_l,A
JR Z,do_X1
EX DE,HL
CALL GETWORD
EX DE,HL
LD A,#7
LD B,A
LD (do_XB+1),A
JR do_XL1
do_X1: BIT sz_hh,A
JR Z,do_X2
LD A,#1
LD B,A
LD (do_XB+1),A
JR do_XL1
do_X2: LD A,#3
LD B,A
LD (do_XB+#1),A
do_XL1: LD C,#4
PUSH DE
do_XL2: SRL H
RR L
RR D
RR E
DEC C
JR NZ,do_XL2
DJNZ do_XL1
LD A,E
do_XAND: AND A,#15
CALL OUTNUM
do_XB: LD B,#15
do_XL3: POP DE
LD A,E
AND #15
CALL OUTNUM
DJNZ do_XL3
do_xe: LD A,#TheType
POP HL
RET
do_c:
CALL GETWORD
LD A,E
do_ce: CALL OUTCHR
JR do_xe
do_s: CALL GETPTR
EX DE,HL
JR do_ce
sizes: .db 0
large: .db 0
field: .db 0
size: .db 0
type: .db 0
defice: .db 0
sign: .db 0
plus: .db 0
space: .db 0
alter: .db 0
zero: .db 0
before: .db 0
after: .db 0
presi: .db 0 ; default 6.
chcount: .dw 0
FlagL: .ascii '-+ #0'
NumL: .ascii '0123456789'
TypeL: .ascii 'diuxXcs'
SztpL: .ascii "lhjztL"
buffer:
.ascii "01234567890123456789012345678901234567890123456789 01234567890000"
.ascii "01234567890123456789012345678901234567890123456789 012345678900001"
__endasm;
}
Кому интересно, как не работает на zx нынешняя версия - глядите 57786
Нужно открыть снапшот, подсунуть эмулятору trd-шку как диск A и в ответ на приглашение bootdev: ввести 0 и нажать энтер
Вот только в память 128-го помимо ядра влазит всего два 32-кб процесса, и после загрузки системы оба уже есть (init и шелл). Так что больше ничего запустить не выйдет.
Чуть более интересная сборка с хакнутым маппером страниц. Поддержан стандарт Pentagon-512 (и выставлять в эмуляторе нужно именно его), благодаря чему появилась возможность стартовать процессы из оболочки. Но маппер именно что хакнутый: одновременных процессов все равно может быть лишь два, из-за чего вернуться назад в init (команда exit в шелле) уже не выйдет.
57794
57793
Круто! Теоретически, можно уже даже софты писать?
Или их без хитропропатченного SDCC не соберёшь?
Увы. На реале не запускается :(
Круто! Теоретически, можно уже даже софты писать?
Или их без хитропропатченного SDCC не соберёшь?
Соберешь. Хитропатченный SDCC нужен лишь ядру - чтобы кросс-баночные CALL-ы делать.
У приложений же память линейная, можно собирать чем угодно.
Увы. На реале не запускается :(
Ммм, а ты как SNA на реале грузишь? Пентева умеет? Тогда в случае второго ядра там возможно та же фишка, что и в анриле по-умолчанию - при загрузке 128к-снапшота отключаются все расширения памяти.
А с первым не знаю даже, что может быть. До запроса устройства для загрузки оно даже в самых примитивных эмуляторах доходит.
Чтобы собирать, что нужно? - специальный crt0, слинковать под нужный адрес, да засунуть в образ ФС на дискету?
Да, Пентева с TS-config умеет SNA запускать. Определяется 512 к памяти. Нормально работает вплоть до ввода бутового устройства - потом висяк и белый бордюр. Но я пока только с образа дискеты пробовал. Надо еще с реальной дискетой попробовать - может в этом дело?
Думаю, чем бы на дискетку-то перенести. Дисковод только на Пентеве.
- - - Добавлено - - -
Eltaron, а можешь ли мою печаталку заюзать (токо там шрифт под 1251), и есть ли в этом смысл сейчас в контексте высвобождения памяти?
- - - Добавлено - - -
Eltaron, сможешь ли пофиксить запускалку SNA, если исходник есть? что не должно гробиться? Можно для реала (Пентева/тс-конфа) сделать запускалку FUZIX.
- - - Добавлено - - -
Прилагаю образ винта для анрила с Wild Commander`ом.
Нажимаем L_SHIFT+F12 - заходим в коммандер. нажимаем курсор на трдшнике с ФС, ставим его на дисковод А. Затем нажимаем курсором на файл SNA.
Возможно дебаггер анрила поможет выяснить, где "собака зарыта".
Чтобы собирать, что нужно? - специальный crt0, слинковать под нужный адрес, да засунуть в образ ФС на дискету?
Вот, держи
https://yadi.sk/d/RuJwBxduu5uQx
Это printf(hello, world) со всеми зависимостями. Для сборки нужен только обычный sdcc.
Там же скомпиленные под винду утилиты (ucp, mkfs и binman) на всякий.
Eltaron, а можешь ли мою печаталку заюзать (токо там шрифт под 1251), и есть ли в этом смысл сейчас в контексте высвобождения памяти?
Смысл есть в плане освобождения места на 128-килобайтных моделях. Там сейчас просто ужас с памятью, она тупо кончилась.
Там же, где страниц побольше, смысл только в большей скорости. Что тоже, в общем-то, неплохо.
Я сделаю сборку с ней, не сегодня только.
Eltaron, сможешь ли пофиксить запускалку SNA, если исходник есть? что не должно гробиться? Можно для реала (Пентева/тс-конфа) сделать запускалку FUZIX.
Прилагаю образ винта для анрила с Wild Commander`ом.
О, спасибо. На самом деле такой баг (белый бордер + зависон и никакой активности ВГ93) я иногда ловлю и в эмуляторе обычного пентагона. Но очень рандомно, так что будет хорошо, если на пентеве он вызывается тем же косяком, можно одним выстрелом попробовать пофиксить всех зайцев.
- - - Добавлено - - -
Нет, тут другое. Весь косяк в том, что при #3d2f не происходит подмены ROM.
Возможно, что SNAпшотогенерилка не ставит какие-то флаги, по которым эмулятор должен понимать, что за конфигурация и ромсет должна быть у машины.
- - - Добавлено - - -
Да в общем-то ведь наплевать тут на #3d2f, это же костыль для классических бетадисков. Ну а на ТС-конфе ведь наверняка есть прямой доступ к портам ВГ93 (в бейзе-то точно есть, там же CP/M)? Где-нибудь про это почитать можно?
- - - Добавлено - - -
Нашел - http://hype.retroscene.org/blog/dev/209.html
Порт FDDVirt (#29af) использует 4 младших бита, каждый из которых указывает на все доступные дисководы А — D
Дисковод срабатывает при таких условиях:
— бит нужного дисковода = 1.
— выбран соотв. флоп в порту FF[1:0]
— включен трдос
— произошло обращение к любому порту бетадиска
При этом происходит включение паги 255 по адресу 0-3ффф
любое обращение к любому порту бетадиска вызывает отключение паги 255
Гм, серьёзно что ли только через TR-DOS?
Гм, серьёзно что ли только через TR-DOS?
Угу. :(
Зато можно кастомный ROM подставить
Зато можно кастомный ROM подставить
А как подставить родной BASIC48?
Когда SNA стартует, у него в 0000 стоит страница RAMFB, в которую скопирован ROM c BASIC48. Окей, согласен, что для нужд загрузки снапшотов (и тем более tap-ок) так удобней. Но как теперь воткнуть на его место нормальный BASIC48, и чтоб автоподключение TR-DOS по M1+3dxx работало? Что и в какие порты записать?
Я в этом tsconf.xls уже весь мозг сломал. Мне сегодня все эти #21AF сниться будут, не иначе :)
А как подставить родной BASIC48?
Короче, запустил Фузикс под эмулем из WC в ручном режиме через дебаггер.
Как советовал Коши, поставил брейк на #3CC0
после кода, переключающего странички поставил джамп на #4000, а там дописал такой код:
di
ld l,#0xC0 ; включаем ROM
ld bc,#21af ; MemConfig
out (c),l
ld b,#0x10 ; #_tsPage0
ld l,#0x03 ; ROM Basic-48
out (c),a
ei
Дальше продолжение той подпрограммы:
ld hl,0
ld bc,0
ld sp,0
nop
out jp #c003
Я думаю, Коши согласится поправить этот момент.
В крайнем случае, есть исходник запускалки.
а что это за команда такая, ld nop ?
В крайнем случае, есть исходник запускалки.
Разумнее, наверное, прямо в инициализацию фузикса этот код вставить. Если, конечно, проблема только у его SNAпов.
Ну, вставь, пожалуйста.
Кстати, можешь ли сделать кратенькую инструкцию как засунуть прогу для Fuzix на трдшник?
вы какие-то очередные кастыли изобретаете. если пилите попытку запуска на ТС конфе, запилите нормальный бутсектор для сд карты или винта (хотя какой там винт, там же нет теперь винта). зачем со снапшотами такие вещи извращать, особенно когда нет прямого доступа к ВГ93?
вы какие-то очередные кастыли изобретаете. если пилите попытку запуска на ТС конфе, запилите нормальный бутсектор для сд карты или винта (хотя какой там винт, там же нет теперь винта). зачем со снапшотами такие вещи извращать, особенно когда нет прямого доступа к ВГ93?
В смысле зачем? Затем, чтобы рабочее решение было прямо сейчас, а не ещё через два года, когда SfS или кто-нибудь ещё захочет попортировать фузикс на пентеву ещё немножко.
Кстати, можешь ли сделать кратенькую инструкцию как засунуть прогу для Fuzix на трдшник?
ucp filesystem-zx128.trd
> bget hello
> chmod 777 hello
> exit
всё
ElTaron, пропатчил я снапшот: разместил код, переключающий ПЗУ c #BFE8. Переход на этот адрес делается джампом, который шёл ранее на #C037/ выход из патча на этот адрес сделал. Теперь под эмулем из WC нормально работает. На реале получилось пару раз пройти бут-девайс.
Но вот что получил:
bootdev:
panic: getproc: extra running
Правда, с реальной дискеты не пробовал пока.
p.s.
запускать fuzixwc.sna
В смысле зачем? Затем, чтобы рабочее решение было прямо сейчас
ну т.е. нормальный лоадер (boot sector) под сд это типа не рабочее решение прямо сейчас (+ на постоянку)? тогда ладно, пусть будет очередной кастыль (и это мягко сказано).
panic: getproc: extra running
Подозреваю, что это банкинг работает не так, как я думал.
попробуй 57833
Это обычная 128 версия, но с твоим патчем. В ts-эмуле грузится.
- - - Добавлено - - -
прямо сейчас
Ой, это где? Или это читать как "прямо сейчас, вот только два человека, у одного из которых нет компилятора, а у другого пентевы, напишут бутлоадер и драйвер карты"? Это далеко не "прямо сейчас" в таком случае.
Но вообще патчи и пулл-реквесты are always welcome, присылай если что :)
попробуй 57833
Это обычная 128 версия, но с твоим патчем. В ts-эмуле грузится.
Да в тс-эмуле и предыдущий патченный снапшот работал. Но на реале из десятков попыток только 2 раза прошёл бут-девайс. В остальных - висяк с белым бордюром.
А в присланном тобой, увы, на реале пока только висяк :(. Как бы узнать, ну что ему не хватает! Ещё попытаюсь.
О, я понял, почему у меня иногда в эмуле висло. Там ведь сейчас прерывания в IM2 (=обработчик сидит в RAM). Соответственно, если оно приходит в тот момент, когда мы уже в TR-DOS'ном роме, но ещё не сделали DI, то происходит M1 из оперативы, TR-DOS выключается и возврат из прерывания происходит куда попало. Починил, теперь работает стабильно.
Пофиксил и собрал 128 и 512 версии, можешь проверить, авось и на реале в этом дело 57835
Eltaron, вы странные ребята. Документация на ТС есть? Компилятор (речь, видимо, про какую-то версию сдцц) разве не общедоступен? А эмулятор разве в тс конфе не эмулит сд кару и другие мутки конфы? У вас в наличии ещё и живой автор конфы, а вы очередной кастыль пилите.
Тс конфа, как я помню, при включении начинает активно искать и гонять сд карту, искать и грузить файл boot.c$. Ну так вы подсуньте лоадер в этот бут.ц на фате, а вторым разделом фузикс фс. Странно, но старая версия фузикса несколькими страницами ранее именно так и работала.
Пофиксил и собрал 128 и 512 версии, можешь проверить, авось и на реале в этом дело
Ура! - Заработало! :)
Теперь очевидно, что надо бы турбу включать
Впрочем, это можно отдельной софтиной сделать.
Очень не хватает 64 символа в строке. Но походу, для красивого вывода, всё-таки придётся мне принтф допилить.
вы очередной кастыль пилите
Твое сообщение длиннее этого костыля в ~7 раз :)
И очевидно, что на данном этапе нативный фузикс-раздел - это зло. Потому что закидывать на него файлы - это боль.
И, главное, та "старая версия фузикса несколькими страницами ранее" по нынешним меркам представляет собой костыль чуть более, чем полностью.
- - - Добавлено - - -
Очень не хватает 64 символа в строке.
А в тсконфе АТМовский текстовый режим остался или выпилили?
А в тсконфе АТМовский текстовый режим остался или выпилили?
А в тсконфе АТМовский текстовый режим остался или выпилили?
В ТС-конфе никогда не было АТМовского текстового режима. Там свой, более удобный.
В VPage указывается страница текстового экрана, в страницу VPage xor 1 загружается фонт в обычном формате 8 байт на символ.
Формат экрана 128 символов на 64 строки. Одна строка занимает 256 байт: первые 128 байт - коды символов (отображаются только первые 80, горизонтального скролла нет), далее 128 байт атрибуты для каждого кода символа, соответственно. 4 бита фон, 4 бита тон (или наоборот?). Текстовый экран можно аппаратно скроллить по вертикали.
Кстати, текстмод может лежать на любой паге. фонт на смежной - т.е. 5/4, 4/5
Текстовый экран можно аппаратно скроллить по вертикали.
Расскажи как,чего то ,я не вычитал такого.
Расскажи как,чего то ,я не вычитал такого.
Ну, по вертикали - теми же регистрами как и для остальных режимов: GYOffsL/"GYOffsH - #04af/#05af.
- - - Добавлено - - -
Eltaron, скомпилил и засунул в трдшник hello.c и more.c - ни тот, ни другой не запускаются :(
кроме того, не понял, как их в /bin засунуть - команда "cp" ничего не делает.
Ай нид хелп, вобсчем :)
Eltaron, скомпилил и засунул в трдшник hello.c и more.c - ни тот, ни другой не запускаются :(
кроме того, не понял, как их в /bin засунуть - команда "cp" ничего не делает.
Ай нид хелп, вобсчем :)
Держи видос :)
https://www.youtube.com/watch?v=goHw0ngFQvo
Держи видос :)
Ну вот, совершенно другое дело: всё работает. Команда more выводит содержимое текстовых файлов.
Оказывается, переходить в bin нужно было в самой оболочке ucp!
Спасибо!
Оказывается, переходить в bin нужно было в самой оболочке ucp!
можно вообще не переходить
но тогда запускать придется по полному пути - /more и т.п.
можно вообще не переходить
но тогда запускать придется по полному пути - /more и т.п.
Нет-нет-нет, - всё должно быть так, как должно быть. Корень - не место для приложений.
Ещё вопрос, ucp может принимать команды не из оболочки, а из командной строки? Тогда можно было бы прикрутить сборку к КодеБлокс.
Кстати, добавил ключик "--max-allocs-per-node 200000" - cобирается медленнее, но выигрыш по размеру есть: на more -целых 20 байт.
Наваял простецкую переключалку скорость CPU для тсконфы. cpuspeed speednum (0-2).
Теперь в тс-анриле играться с фузикс будет комфорней. :)
в тс-анриле
Чего то у меня диск еррор пишет,запускаю из WC 0.94 и tr-dos материться.
Чего то у меня диск еррор пишет,запускаю из WC 0.94 и tr-dos материться.
Сам диск не надо запускать. В этом диске от TR-DOS только разметка 256х16х80. Файловая система там совсем другая.
Запускать надо SNA-файл (http://zx-pk.ru/attachment.php?attachmentid=57835&d=1470951887)
Смотри видео (https://youtu.be/goHw0ngFQvo?t=1m58s), там все есть.
- - - Добавлено - - -
Ещё вопрос, ucp может принимать команды не из оболочки, а из командной строки? Тогда можно было бы прикрутить сборку к КодеБлокс.
Да, она принимает команды во входном потоке.
echo "cd bin
get hello
chmod 777 hello" | ucp filesystem-zx128.trd
В прошлый раз я добавил программку cpuspeed. Думаю, результат её работы и так виден невооружённым взглядом. Но для объективного контроля изменения производительности решил запилить bogomips. Алгоритм не аутентичный, но по смыслу похож: замеряем количество пустых циклов в тике. А тик у нас = 1/50 секунды.
Цикл следующий:
loop dec bc
ld a,b
or c
jr nz,loop
занимает 26 тактов.
Результат даже похож на правду: для 3,5 МГц 2759*26=71734. :)
- - - Добавлено - - -
Кстати, обратил внимание:
1) printf() не умеет печатать числа с плавающей запятой,
2) консоль не умеет CSI коды.
- - - Добавлено - - -
Замечание: если кто будет использовать ассемблерные вставки, то пусть уберёт опцию --peep-asm - иначе компилятор в вашем коде накуролесит - заколебётесь баги искать.
Кроме того, в большинстве случаев добавление опции --reserve-regs-iy делает код более быстрым, и нередко более коротким.
2) консоль не умеет CSI коды.
Консоль умеет, реализация терминала для ZX - нет. Я там как набросал её по быстрому в самом начале, так оно с тех пор и не менялось. Цвета там пока не предусмотрено.
Eltaron, не терпится увидеть фузикс в нормальном текстовом режиме на тсконфе: вот переписал модуль zxvideo (исходный взял с гитхаба Алана Кокса).
Задействовал аппаратный скролл. Написал функцию _vtattr_notify (я так понял, это установка атрибутов экрана). Курсор теперь выделяется не подчёркиванием, а сменой атрибутов. Переписал процедуру _do_beep, - четверть секунды должна звучать нота "ля" средней октавы.
Предполагается, что с адреса 0x0000 будет включена видеостраница, а перед обращением к дисководу необходимо временно включать ПЗУ (48?).
Поскольку, максимально поддержана память до 512кБ, предлагаю использовать для текстового экрана страницу 32, для шрифта - 33 (32xor1).
И, да, при загрузке системы, надо как-то загрузить 2кб шрифта - любой понравившийся стандартный спектрумовский шрифт (не в формате экрана) на 256 символов.
Может, сделаешь спецсборку на досуге? :v2_rolley
Процедура включение в CPU0 видеостраницы:
di
ld bc,#0x21af ;_MemConfig
ld a,#0xCE
out (c),a
ld b,#0x10 ; #_tsPage0
ld a,#RAMPGNUM ; 32/33
out (c),a
ei
Процедура включение в CPU0 ПЗУ:
di
ld bc,#0x21af ;_MemConfig
ld a,#0xC0
out (c),a
ld b,#0x10 ; #_tsPage0
ld a,#ROMnum
out (c),a
ei
ret
Процедура включения текстового видеорежима:
ld bc,#0x01af ; #_tsVPage
ld a,#32
out (c),a
dec b ; #_tsVConfig
ld a,#0x43 ; %01000011, text mode in 320x240pix window.
Собственно, модуль zxvideo. Увы, не тестировал.
;
; PentEVO/TS-Config text mode 320x240 (80x30 chars) vt primitives.
; Modified from original by Amixgris / Red Triangle. 18/08/2016.
;
.module zxvideo
; exported symbols
.globl _plot_char
.globl _scroll_down
.globl _scroll_up
.globl _cursor_on
.globl _cursor_off
.globl _clear_lines
.globl _clear_across
.globl _do_beep
.globl _vtattr_notify
.globl _vtink
.globl _vtpaper
.area _VIDEO
; colors are ignored everywhere for now
videopos: ; video page vith text mode must be mapped on cpu0
ld a,(#_tsconfig_topline_offset)
add a,e
and a,#0x3f
ld e,d
ld d,a
ret
_plot_char:
pop iy
pop hl
pop de ; D = x E = y
pop bc
push bc
push de
push hl
push iy
call videopos
;
; TODO: Map char 0x60 to a grave accent bitmap rather
; than fudging with a quote
;
ld b,#0 ; calculating offset in font table
ld a, c
cp #0x60
jr nz, nofiddle
ld a, #0x27
nofiddle:
ld (de),a ; set char code to text videomemory.
; set char attributes:
ld a,(_tsconfig_screen_mix_color)
set 7,e
ld (de),a
ret
_clear_lines:
pop bc
pop hl
pop de ; E = line, D = count
push de
push hl
push bc
clear_next_line:
push de
ld d, #0 ; from the column #0
ld b, d ; b = 0
ld c, #80 ; clear 80 cols
push bc
push de
push af
call _clear_across
pop af
pop hl ; clear stack
pop hl
pop de
inc e
dec d
jr nz, clear_next_line
ret
_clear_across:
pop iy
pop hl
pop de ; DE = coords
pop bc ; C = count
push bc
push de
push hl
push iy
call videopos ; first pixel line of first character in DE
push de
pop hl ; copy to hl
ld b,#0
ld (hl),#" "
push hl
push de
push bc
ldir
; clear attributes:
ld a,(#_tsconfig_screen_mix_color)
pop bc
pop de
pop hl
set 7,l
set 7,e
ld (hl),a
ldir
ret
copy_line:
; HL - source, DE - destination
; convert line coordinates to screen coordinates both for DE and HL
push de
ex de, hl
call videopos
ex de, hl
pop de
call videopos
ld bc, #80
push hl
push de
push bc
ldir
pop bc
pop de
pop hl
; copy attributes:
set 7,e
set 7,l
ldir
ret
_scroll_down:
ld bc,#8
_scrldn:
ld hl,(#_tsconfig_topline_offset)
add hl,bc
ld (#_tsconfig_topline_offset),hl
ld bc,#0x04af ; GYOffsL
out (c),l
inc b
out (c),h
ld a,l
srl h
rra
rra
rra
and a,#0x3f
ld (#_tsconfig_topline_offset),a
ret
_scroll_up:
ld bc,#-8
jr _scrldn
_cursor_on:
pop bc
pop hl
pop de
push de
push hl
push bc
ld (cursorpos), de
curs: call videopos
set 7,e
ld a,(de)
or a,a
rrca
rrca
rrca
rrca
ld (de),a
ret
_cursor_off:
ld de, (cursorpos)
jr curs
_do_beep: ; do 440Hz dure 1/4s
di
ld bc,#0x00fe
ld h,#110
loop_beep1:
ld de,#298
loop_beep:
dec de
ld a,d
or a,e
jr nz,loop_beep
ld a,l
cpl
ld l,a
and a,#0x10
out (c),a
dec h
jr nz,loop_beep1
ei
ret
_vtattr_notify: ; void vtattr_notify(void)
ld a,(#_vtink)
and a,#0x0f
ld (#_vtink),a
rrca
rrca
rrca
rrca
ld c,a
ld a,(#_vtpaper)
and a,#0x0f
ld (#_vtpaper),a
or a,c
ld (_tsconfig_screen_mix_color),a
ret
.area _DATA
_vtink:
.db 7
_vtpaper:
.db 0
_tsconfig_screen_mix_color:
.db 0x07
_tsconfig_screen_offset:
.dw 0
_tsconfig_topline_offset:
.db 0
cursorpos:
.dw 0
- - - Добавлено - - -
Сам шрифт можно наживую в снапшот засунуть, в экранную область, а в инит добавить копирование его в 33-ю пагу.
можно просто лдиром, включив пагу вместо ПЗУ с помощью представленной процедуры.
- - - Добавлено - - -
Есть ещё идея обойтись без переключения паг в области ПЗУ, а копировать данные в экран с помощью ПДП, - но не продумал пока, есть ли в этом преимущество.
Может, сделаешь спецсборку на досуге? :v2_rolley
Собрал, не работает. Проблема в том, что вот тут
; set char attributes:
ld a,(_tsconfig_screen_mix_color)
set 7,d
ld (de),a
на входе DE = 0, после set 7,d оно превращается в 8000, куда и пишется рандом из аккумулятора
Но 8000 - это начало секции DISCARD. Туда очень скоро произойдет переход и всё завалится из-за попытки исполнить записанные данные.
Ты, наверное, планировал какую-то другую страницу в 8000 подставлять, или я чего-то недопонимаю в организации памяти тсконфы?
Результат даже похож на правду: для 3,5 МГц 2759*26=71734.
А как понять поподробнее,так же считают современные процы?
Собрал, не работает. Проблема в том, что вот тут
; set char attributes:
ld a,(_tsconfig_screen_mix_color)
set 7,d
ld (de),a
на входе DE = 0, после set 7,d оно превращается в 8000, куда и пишется рандом из аккумулятора
Но 8000 - это начало секции DISCARD. Туда очень скоро произойдет переход и всё завалится из-за попытки исполнить записанные данные.
Ты, наверное, планировал какую-то другую страницу в 8000 подставлять, или я чего-то недопонимаю в организации памяти тсконфы?
Лять! Голова моя садовая! Нужно не D, а E! SET 7,E. Установленный старший разряд младшего байта адреса знакоместа "переносит" нас к его атрибуту! В общем, везде, где устанавливается 7-й бит в модуле, нужно поменять старший регистр регистровой пары на младший.
Поправил исходник в сообщении.
Кстати, а почему в аккумуляторе рандом? - там должен лежать код атрибутов. по девфолту #0x07 (или наоборот :) )
- - - Добавлено - - -
А как понять поподробнее ,что умножаем,сижу и не могу понять откуда цифры 2759
если ты запускал bogomips, то видел результат его работы - число в BogoMIPS. Например, для 3,5MHz - 0,002759. Это означает, что за однин тик (одно прерывание в нашем случае) успело выполниться 2759 циклов. Цикл занимает 26 тактов. Умножая количество циклов на их длительность, получим количество тактов в прерывании.
У пентагона 71680 тактов в прерывании, у меня получилось 71734, - всего на 54 такта погрешность.
- - - Добавлено - - -
Не рандом, а НОЛЬ! Пофикил исходник:
_tsconfig_screen_mix_color: .db 0x07
Это означает, что за однин тик (одно прерывание в нашем случае) успело выполниться 2759 циклов
это понятно что под цикл подобрали количество проходов в прерывании ,мне интересно понять как сравнить с современными процессорами,там считаются тоже нопы по такой же схеме?запуск на смарте меня шокировал своими цифрами,вот и интересуюсь насколько сравнимы эти тесты,вот некоторые x86 процессоры, выпущенные в 2010-х, способны исполнять до 4 операций nop каждый такт.получается у них жульничество.Извиняюсь за глупые вопросы ,никогда не интересовался такими вещами.
Я ничего не "подбирал" - всё вычисляется.
Как реализовать оригинальный алгоритм, я не понял.
В оригинале используется такой цикл:
1: decl ax
jns 1b
Я решил, что более близкий по смыслу цикл на z80 будет такой:
loop: dec bc
ld a,b
or c
jr nz,loop
А, вообще, bogomips - это не тест производительности, хотя определённое представление о производительности он даёт, а сугубо прикладная задача - калибровка задержек, необходимых системе.
Результат будет зависеть и от скорости процессора и от длительности тиков. Какой длительности тики используются в Linux, я не знаю.
/*
* Standalone BogoMips program (a la BogoMips)
* Amixgris / RT 08/2016
*
*/
#include <stdio.h>
long rd_cmos_hms_w(void) __naked;
long rd_cmos_hms(void) __naked;
long iBCDlong(long n) __naked;
int dtime,m,n;
long t1,t2;
void main(void)
{
printf("Calibrating delay loop.. ");
fflush(stdout);
t1 = rd_cmos_hms_w();
__asm
ld bc,#0x00
di
.rept 80
.db 0x0b,0x78,0xb1,0x20,0xfb ; loop: dec bc
; ld a,b
; or c
; jr nz,loop
.endm
ei
__endasm;
t2 = rd_cmos_hms();
t1 = iBCDlong(t1);
t2 = iBCDlong(t2);
dtime = t2-t1;
m = 0x500000/dtime/50;
printf("ok -\n0,00%u BogoMIPS\n",m);
}
long rd_cmos_hms(void) __naked
{
__asm
ld bc,#0xeff7
ld a,#0x80
out (c),a
ld b,#0xdf
xor a,a
out (c),a
ld b,#0xbf
in l,(c)
ld b,#0xdf
ld a,#2
out (c),a
ld b,#0xbf
in h,(c)
ld b,#0xdf
ld a,#4
out (c),a
ld b,#0xbf
in e,(c)
ld b,#0xef
xor a
out (c),a
ld d,a ; result in dehl
ret
__endasm;
}
long rd_cmos_hms_w(void) __naked
{
__asm
ld bc,#0xeff7
ld a,#0x80
out (c),a
ld b,#0xdf
xor a,a
out (c),a
ld b,#0xbf
1$: in a,(c)
jr nz,1$
ld l,a
ld b,#0xdf
ld a,#2
out (c),a
ld b,#0xbf
in h,(c)
ld b,#0xdf
ld a,#4
out (c),a
ld b,#0xbf
in e,(c)
ld b,#0xef
xor a
out (c),a
ld d,a ; result in dehl
ret
__endasm;
}
long iBCDlong(long n) __naked
{ n;
__asm
pop af
pop de
pop bc
push bc
push de
push af
push de
xor a,a
ld d,a
ld e,a
ld h,a
ld a,c
rrca
rrca
rrca
rrca
and a,#0x0f
call 4$ ; mul 10
ld d,a
ld a,c
and a,#0x0f
add a,d
ld d,#0
ld l,a
call 2$ ; 10*DEHL
call 3$ ; 6*DEHL ; mul hours by 60 = minutes.
pop bc
ld a,b
rrca
rrca
rrca
rrca
and a,#0x0f
call 4$ ; mul 10
ld d,a
ld a,b
and a,#0x0f
add a,d
ld d,#0
call 1$ ; add A to DEHL
call 2$ ; 10*DEHL
call 3$ ; 6*DEHL ; mul minutes by 60 = seconds.
ld a,c
rrca
rrca
rrca
rrca
and a,#0x0f
call 4$ ; mul 10
ld d,a
ld a,c
and a,#0x0f
add a,d
ld d,#0
call 1$ ; add A to DEHL ; add seconds.
ret
1$: add a,l ; add8to32
ld l,a
ld a,h
adc a,#0
ld h,a
ld a,e
adc a,#0
ld e,a
ld a,d
adc a,#0
ld d,a
ret
2$: push bc ; 32b*10:
add hl,hl
ex de,hl
adc hl,hl
ex de,hl
push de
push hl
add hl,hl
ex de,hl
adc hl,hl
ex de,hl
add hl,hl
ex de,hl
adc hl,hl
ex de,hl
pop bc
add hl,bc
ex de,hl
pop bc
adc hl,bc
ex de,hl
pop bc
ret
3$: push bc ; 32b*6:
add hl,hl
ex de,hl
adc hl,hl
ex de,hl
push de
push hl
add hl,hl
ex de,hl
adc hl,hl
ex de,hl
pop bc
add hl,bc
ex de,hl
pop bc
adc hl,bc
ex de,hl
pop bc
ret
4$: add a,a
ld d,a
add a,a
add a,a
add a,d
ld d,#0
ret
__endasm;
}
- - - Добавлено - - -
Ну, и, как бы целью написания мной богомипсов было не замерить производительность, а получить возможность проверки результата работы cpuspeed.
Собрал. Не работает, ресетит машину.
Я там дописал переключение банки при выводе текста и инициализацию в crt0.s
При выходе из инициализации банки стоят верные, в страницу 33 скопирован фонт из ROM
Но я ни разу не видел, чтоб текстовый режим вообще запустился. Может быть что-то всё же недоинициализировал?
Исходник https://github.com/atsidaev/FUZIX/commit/d74f77f8dda616050d2fe3db7c79b7edbdf1fc6d
sna и map, если захочешь поотлаживаться 57920
буду ловить тараканов, но, скорее, уже только сегодня вечером после 9. :(
- - - Добавлено - - -
Для начала, у тебя текст пишется в ROM3. Я упоминал о том, что RAM 32 должна быть включена с 0x0000 ВСЕГДА, и лишь для доступа к дисководу временно замещаться ROM 3. Сделал ли ты так?
Ковыряю дальше
- - - Добавлено - - -
А вот почему не включается текстовый режим. Кусок кода его инициализации:
; text mode
ld bc,#0x01af ; #_tsVPage
ld a,#32
out (c),a
dec b ; #_tsVConfig
ld a,#0x43 ; %01000011, text mode in 320x240pix window.
ld a, #7
ld (_vtink), a
Вместо записи номера режима в порт, идет загрузка аккумулятора числом 7.
- - - Добавлено - - -
Что касается установки цвета. После записи значений цветов для ink и paper необходимо вызвать процедуру _vtattr_notify - она занесёт необходимое значение в переменную _tsconfig_screen_mix_color, которая используется при установке атрибутов печатаемого символа.
Для начала, у тебя текст пишется в ROM3. Я упоминал о том, что RAM 32 должна быть включена с 0x0000 ВСЕГДА, и лишь для доступа к дисководу временно замещаться ROM 3. Сделал ли ты так?
Я сделал наоборот, что всегда ROM, но на время plot_char включается RAM32
А вот почему не включается текстовый режим. Кусок кода его инициализации:
; text mode
ld bc,#0x01af ; #_tsVPage
ld a,#32
out (c),a
dec b ; #_tsVConfig
ld a,#0x43 ; %01000011, text mode in 320x240pix window.
ld a, #7
ld (_vtink), a
Вместо записи номера режима в порт, идет загрузка аккумулятора числом 7.
А, это я твой кусок скопировал и не осмыслил. Там тоже out не было. Добавил, режим включается, но экран заполнен мусором и буков не видно. Сами буквы в 32ю пагу пишутся, я проверял.
7 в A грузится, чтоб инициализировать _vtink. У тебя она в исходнике описана как локальная переменная с .db #7, но на деле она хранится в vt.c, поэтому приходится.
Что касается установки цвета. После записи значений цветов для ink и paper необходимо вызвать процедуру _vtattr_notify - она занесёт необходимое значение в переменную _tsconfig_screen_mix_color, которая используется при установке атрибутов печатаемого символа.
в том коде, что в ветке в git, я вообще вместо _tsconfig_screen_mix_color всегда вывожу 7, чтоб наверняка
- - - Добавлено - - -
В общем, добавил di:halt в _plot_char, чтобы вешалось сразу после вывода первого символа. Состояние в халте - RAM32 в 0000, по адресу 0000 - 'F', по адресу 0080 - 0x07. Верный символ с верным атрибутом в верной паге. Но на экране чернота.
Коммит (https://github.com/atsidaev/FUZIX/commit/2217a3140d89520e1b7b8417b0484a2b5a6c857a)
Снапшот 57927
- - - Добавлено - - -
В странице 33 лежит шрифт из ROM. Пробел по адресу 0x100 ведь должен быть? Первые 256 байт шрифту обрезать не нужно?
может я не въехал в суть вопроса,но так на всякий
ld bc,#0x01af ; #_tsVPage
ld a,#32 - а включена страница #20
out (c),a
dec b ; #_tsVConfig
ld a,#0x43 ; %01000011, text mode in 320x240pix window.
out (C), a
может я не въехал в суть вопроса,но так на всякий
Да-да, оно счас так и есть (https://github.com/atsidaev/FUZIX/blob/2217a3140d89520e1b7b8417b0484a2b5a6c857a/Kernel/platform-zx128/crt0.s#L138)
Режим переключается. Но почему-то сразу после переключения экран черный (хотя и в 32, и в 33 лежит мусор, оставшийся от WC), а где-то через секунду выводятся цветные прямоугольники вроде бы нужного размера.
И вот чувство, что за эту секунду происходит какая-то дополнительная инициализация, возможно даже и не предусмотренная (в результате исполнения данных или куска ПЗУ), из-за чего появляется картинка.
Начнём, помолясь.
Во-первых, включать ОЗУ надо не только перед _plot_char, но и:
_clear_across,
copy_line,
_cursor_on,
_cursor_off. - ВСЕ они производят запись в видеопамять, а там ВНЕЗАПНО ПЗУ! :)
Остальное пока в процессе - никогда у меня с текстовым режимом ничего путного не получалось :(
- - - Добавлено - - -
Elaron, привет!
Поэкспериментировал в Аласме. Тестовый режим запустился нормально. Однако, не совсем понятно, что мы делали не так. Вроде, инициализация один в один. Предлагаю заменить код инициализации режима на этот. Добавил выставление Y-координаты текстового окна в 0 - хз что там после WC было.
Также добавил очистку текстового экрана - все 64 строки (видимых 30). Вызов очистки не по феншую, но, думаю, ввиду неизменности первых 6-ти байт (POP/PUSH) не фатально.
Дальше думаю, сделать отдельные подпрограммки включения/выключения видеопамяти и засунуть их непосредственно в модуль zxvideo.
; making sure that we have Basic48 as ROM
ld bс, #0x21af ; 0x21af is the MemConfig port of TS-Conf
ld l,#0xC0 ; Enable ROM instead of RAM in #0000
out (c),l
ld b,#0x10 ; #_tsPage0 port (0x10af)
ld l,#0x03 ; ROM Basic-48
out (c),l
; map basic-48
ld bc, #0x7ffd
ld a, #0x18
out (c), a
; setting Font in page 0x33
ld b,#0x12af ; #_tsPage1 port (0x12af)
ld l,#33
out (c),l
ld hl,#0x3D00 ; font data in ROM,
ld de,#0x8100 ; skip data for first 20 char codes.
ld bc,#0x300
ldir ; copy font data to page 33
ld b,#0x12af ; #_tsPage1 port (0x12af)
ld l,#2 ; put RAM2 back
out (c),l
; ld bc,#0x10af
; ld l, #32
; out (c), l ; set ram to 0000
; ld b, #0x21 ; 0x21af is the
; ld c, #0xaf ; MemConfig port of TS-Conf
; ld l,#0xCE ; Enable RAM instead of ROM in #0000
; out (c),l
; ld b,#0x10 ; #_tsPage1 port (0x11af)
; ld c,#0xaf
; ld l, #32
; out (c), l
; text mode:
; set vertical screen position to 0.
ld bc,#0x04af ; GYOffsL
xor a,a
out (c),a
inc b ; GYOffsH
out (c),a
; set up video memory to RAM page 0x20:
ld bc,#0x01af ; #_tsVPage
ld a,#32
out (c),a
dec b ; #_tsVConfig
ld a,#0x43 ; %01000011, text mode in 320x240pix window.
out (c),a
ld a,#7
ld (_vtink),a
ld a,#1
ld (_vtpaper),a
call _vtattr_notify
; clear videomemory:
ld d,#64 ; lines
ld e,#00 ; from 0.
call _clear_lines+6 ; (clear_next_line).
- - - Добавлено - - -
Сегодня буду отлаживать весь модуль на работоспособность в alasm/sts.
Также добавил очистку текстового экрана - все 64 строки (видимых 30). Вызов очистки не по феншую, но, думаю, ввиду неизменности первых 6-ти байт (POP/PUSH) не фатально.
На самом деле фатально, там же хитрый маппер. Но я пофиксил всё (https://github.com/atsidaev/FUZIX/commit/b99eb7ad829301fb423391a9e9bc29a4ecb85369). Картина, увы, та же самая - черный экран.
На самом деле фатально, там же хитрый маппер. Но я пофиксил всё. Картина, увы, та же самая - черный экран.
А установка видеопамяти вызывается теперь перед всеми функциями, которые я перечислил?
Скинь, пожалуйста, новый снапшот после фикса.
- - - Добавлено - - -
Сейчас вот исходник для аласма подготовил. По-пробую без фузикса видеодрайвер поднять.
А установка видеопамяти вызывается теперь перед всеми функциями, которые я перечислил?
Я её везде отключил, сейчас внизу всегда 32я страница. Плюс оно счас намеренно халтится в _plot_char, так что другие функции даже не пытаются исполняться.
Вообще ты прав, надо подключать ром для бетадиска, в остальное время там пусть видеопамять будет.
Ради вывода одного символа дергать туда-обратно два порта - это слишком накладно.
Снапшот 57938
- - - Добавлено - - -
А в unrealts нет возможности посмотреть, что в xxAF-порты выведено? Сравнить бы их состояние у WC и у фузиха.
Ну, пока, для отладки так оставим. подсчитал: даже с дёрганьем для каждого символа быстрее получается. На дёрганье уходит 111 тактов. Вывод битмапа с вычислениями координат и положения в шрифте - не менее 370 тактов.
Кстати нашёл ошибку - у меня HL и DE для LDIR`а одним и тем же значением загружаются! :) Лошаро!
Строка не чистилась.
- - - Добавлено - - -
Всё, отлаживаю в аласме/стс. Как будет результат, запощу, и можно будет фузикс фиксить.
- - - Добавлено - - -
АХТУНГ!!!! Сейчас очень авторитетный товарищ понаблюдав за нашими мучениями со стороны, наконец, сжалился :) и выдал вот это: (http://f20.ifotki_.info/org/bf9066c9d6483deccbf2caad4d8fa7f45f1b5f254347280.pn g)
Короче, в VPage-регистре вместо 32 паги - стоит 7-я. А всё потому, что, оказывается, "когда делаешь аут 7ффд включается или 5 или 7 видеопага".
(маппер в конфе один, а вот "ворота" к нему разные: 0xNNAF и 7FFD).
Т.е. надо переделывать маппер фузикса на тс-регистры целиком. Или, хотя бы, на скорую руку - после каждой записи в 7ffd "насильно" сразу включать 32-ю пагу в VPage.
Кстати нашёл ошибку - у меня HL и DE для LDIR`а одним и тем же значением загружаются! :) Лошаро!
Строка не чистилась.
Это-то я сразу пофиксил.
АХТУНГ!!!! Сейчас очень авторитетный товарищ понаблюдав за нашими мучениями со стороны, наконец, сжалился :) и выдал вот это: (http://f20.ifotki_.info/org/bf9066c9d6483deccbf2caad4d8fa7f45f1b5f254347280.pn g)
Короче, в VPage-регистре вместо 32 паги - стоит 7-я. А всё потому, что, оказывается, "когда делаешь аут 7ффд включается или 5 или 7 видеопага".
(маппер в конфе один, а вот "ворота" к нему разные: 0xNNAF и 7FFD).
О, так уже лучше. Шрифт не подцепляется, но видно, что первый символ отличается.
http://savepic.ru/11026716m.png (http://savepic.ru/11026716.htm)
Уверен, скоро взлетит!
- - - Добавлено - - -
На счет шрифта, - может, перед копированием ПЗУ не то стоит?
oh yeah!
http://savepic.ru/11059472m.png (http://savepic.ru/11059472.htm)
Включалась не та страница ROM и вместо шрифта брался мусор
Затестил аппаратный скролл: работает.
- - - Добавлено - - -
Ура!, заработала! :)
- - - Добавлено - - -
Ждемс новый снапшот. :)
Ждемс новый снапшот. :)
57939
Маппер точно надо переписывать. Экран мерцает из-за постоянного переключения с 7 на 32.
Ну и всё ещё виснет
http://savepic.ru/11011369m.png (http://savepic.ru/11011369.htm)
Hacker VBI
20.08.2016, 15:47
ну мужики жжоте!!
круто!
57939
Маппер точно надо переписывать. Экран мерцает из-за постоянного переключения с 7 на 32.
Ну и всё ещё виснет
Я смотрю, там HALT поймался и PC находится в видеоОЗУ. Как он туда попал? - Мож, со стэком чего?
И цвета инверсные - это мой косяк. в _vtattr_notify порядок ячеек для совмещения цветов в одном байте перепутал.
О, уже дальше :)
http://savepic.ru/11061558m.png (http://savepic.ru/11061558.htm)
Я смотрю, там HALT поймался и PC находится в видеоОЗУ. Как он туда попал? - Мож, со стэком чего?
из-за сильно удлиннившейся инициализации размер сегмента вылез за пределы 16 килобайт, в итоге линкер налинковал всё не туда. Перекинул инициализацию в _DISCARD, ей там и место - она же одноразовая.
Впрочем, сейчас всё тот же халт в видеопамяти ловит...
И артефакты на экране :(
Чо-то со стэком полюбому - наверняка в моём драйвере.
Кста, там где ты принудительно включаешь 32 пагу, я вывод в 7ffd заменил на 13af (без and #18, разумеется) - работает также, но экран не сечётся.
Кста, там где ты принудительно включаешь 32 пагу, я вывод в 7ffd заменил на 13af (без and #18, разумеется) - работает также, но экран не сечётся.
ага, я только вытащил ешё всю работу с 7ffd в отдельный файл, чтоб не копипастить новый порт 10 раз
В общем, дело в прерывании. Там IM2 с I=0x39, соответственно, он вектор прерывания берет из ROM.
Я, кстати, не понимаю, почему оно вообще работает :) У Алана к комментах написано, что по адресам 0x3900..0x39FF в ROM лежат 0xFF, но ведь это не так! По адресу 0x39FF да, лежит 0xFFFF, поэтому на оригинальном ZX все работает. Но на наших-то жесть ведь начнется.
ага, я только вытащил ешё всю работу с 7ffd в отдельный файл, чтоб не копипастить новый порт 10 раз
В общем, дело в прерывании. Там IM2 с I=0x39, соответственно, он вектор прерывания берет из ROM.
Я, кстати, не понимаю, почему оно вообще работает :) У Алана к комментах написано, что по адресам 0x3900..0x39FF в ROM лежат 0xFF, но ведь это не так! По адресу 0x39FF да, лежит 0xFFFF, поэтому на оригинальном ZX все работает. Но на наших-то жесть ведь начнется.
"Звезда в шоке"! Ну чо, надо вектор менять. искать место для таблички 257 байт. Хотя для ZX-EVO таблица не нужна - там ШД стабильна.
- - - Добавлено - - -
Увы, на реале ничего не смогу потестить больше - Только что моя Пентева приказала долго жить :(
Увы, на реале ничего не смогу потестить больше - Только что моя Пентева приказала долго жить :(
Ох, сочувствую...
А я доотлаживался до рабочести.
http://savepic.ru/11013483m.png (http://savepic.ru/11013483.htm)
57942
При работе с бетадиском по экрану такие олдскульные полосочки идут - я не знаю, как замаппить ROM2 черех xxAF, поэтому извращаюсь. Автоматом маппится ROM3, но его 3D2F не включает TR-DOS.
Аппаратный скроллинг глючит. И, как я понимаю, когда tsconfig_topline_offset превысит 64 строки, он поведет себя непредсказуемо?
не знаю, как замаппить ROM2 черех xxAF
также как включали ПЗУ после работы с текстовым экраном, только в 0x10AF записать 2 вместо 3-х. Через 0x10AF устанавливаются и RAM-, и ROM-страницы в зависимости от значения в 0x21AF.
И, как я понимаю, когда tsconfig_topline_offset превысит 64 строки, он поведет себя непредсказуемо?
Эх я - голова-два уха! После каждого изменения значения нужно делать AND #0x3F.
- - - Добавлено - - -
А я доотлаживался до рабочести.
Красавчег!!!
- - - Добавлено - - -
А,нет, - AND #3F есть. - я ещё хлеще накосячил: текущая координата ЛВУ экрана по Y берётся как слово из _tsconfig_topline_offset, а потом делится на 8 и как байт записывается в ту же ячейку!
щас маленько по другому перепишу. оставлю только номер строки, - а из него будет формироваться значение для порта.
- - - Добавлено - - -
По-моему скроллы должны выглядеть вот так:
_scroll_down:
ld a,(#_tsconfig_topline_offset)
dec a
_scrldn:
and a,#0x3f
ld (#_tsconfig_topline_offset),a
ld h,#0
ld l,a
add hl,hl
add hl,hl
add hl,hl
ld bc,#0x04af ; GYOffsL
out (c),l
inc b
out (c),h
ret
_scroll_up:
ld a,(#_tsconfig_topline_offset)
inc a
jr _scrldn
- - - Добавлено - - -
Пока нового снапшота нет, пропатчу старый.
Кстати в аттр_нотифи надо поменять порядок цветов на обратный
По-моему скроллы должны выглядеть вот так:
работает!
- - - Добавлено - - -
57943
работает!
Вот твой пропатченый снапшот. Осталось только от мерцаний избавиться.
- - - Добавлено - - -
Ну что, надо цвет добавить, парсер CSI писать?
Ну что, надо цвет добавить, парсер CSI писать?
Так он уже есть. Надо понять, как его заюзать
https://github.com/EtchedPixels/FUZIX/blob/master/Kernel/vt.c#L202
- - - Добавлено - - -
также как включали ПЗУ после работы с текстовым экраном, только в 0x10AF записать 2 вместо 3-х. Через 0x10AF устанавливаются и RAM-, и ROM-страницы в зависимости от значения в 0x21AF.
Неа. Я пробовал - не работало. Но счас усомнился и перепроверил - нет, мне не показалось. Пишу 2, включается 2. Пишу 3, включается 2. Пишу 4, включается 6. Как будто это 2 + (_tsPage0 >> 2).
Неа. Я пробовал - не работало. Но счас усомнился и перепроверил - нет, мне не показалось. Пишу 2, включается 2. Пишу 3, включается 2. Пишу 4, включается 6. Как будто это 2 + (_tsPage0 >> 2).
В общем, разговаривал с Самим(!), - предписал вместо записи в 0x21af использовать не 0xC0, а 0x0E.
У меня и так работало как-то...
В общем, разговаривал с Самим(!), - предписал вместо записи в 0x21af использовать не 0xC0, а 0x0E.
У меня и так работало как-то...
Но так даже ROM вместо RAM не включается.
Но так даже ROM вместо RAM не включается.
Ну щас сам ещё доку покурю.
Мы сейчас заняты были - пентеву мне чинили по интернету.
И есть хорошая новость - она заработала!
Оказалось, стабилизатор DA3 сдох. Подал питание с ATX-разъёма пока.
- - - Добавлено - - -
Но так даже ROM вместо RAM не включается.
Попробуй записать 0xC1 или, вообще, 0x01. Должно сработать.
Это включит ROM3. ROM 2 включать не надо - он сам включится, когда PC попадёт в определенный интервал адресов.
Попробуй записать 0xC1 или, вообще, 0x01. Должно сработать.
Оу е!
57953
- - - Добавлено - - -
Ну щас сам ещё доку покурю.
А есть она вообще, нормальная дока-то? Или только этот автосгенеренный, такое чувство, из верилога tsconf.xls? :)
Что за секта без нормальной святой книги? :D
Оу е!
Класс! Смотрю, артефакты пропали! Ура!
А я тут тестилку текстового вывода замастырил: touttest
расчитывает количество выводимых символов и скроллов строк в секунду.
трдшник называется по имени добавленной проги.
- - - Добавлено - - -
А есть она вообще, нормальная дока-то? Или только этот автосгенеренный, такое чувство, из верилога tsconf.xls?
Ну как, - он и есть дока, - интуитивнопонятный же, типа. :)
Ну что, пока можно передохнУть, а там впереди добавление цвета. :)
Smalovsky
21.08.2016, 20:41
У тэсэла появиться официальная ОС?
У тэсэла появиться официальная ОС?
Я о таких планах не знаю. Разве что Бриз сделает CLI3.
Добавил в модуль "zxvideo" для платформы "zx128:"
- поддержку цвета (+22 байта). Смешанный цвет берётся из _vtattr. Поддерживается "как бы" 16 цветов: если код хотя бы одного из атрибутов больше 7, включается яркость. Данное изменение замедляет вывод символа на 78 тактов.
- функцию _vtattr_notify (+27 байт).
- работающий beep (880Гц., 1/8с.)
;
; zx128 vt primitives
;
.module zxvideo
; exported symbols
.globl _plot_char
.globl _scroll_down
.globl _scroll_up
.globl _cursor_on
.globl _cursor_off
.globl _clear_lines
.globl _clear_across
.globl _do_beep
.globl _vtattr_notify
.area _VIDEO
; colors are ignored everywhere for now
videopos:
ld a,e
and #7
rrca
rrca
rrca
add a,d
ld d,e
ld e,a
ld a,d
and #0x18
or #0xC0 ; not 0x40 as in screen 7
ld d,a
ret
_plot_char:
pop iy
pop hl
pop de ; D = x E = y
pop bc
push bc
push de
push hl
push iy
ld h,e
ld l,d
xor a,a
srl h
rra
srl h
rra
srl h
rra
or a,l
ld l,a
ld a,h
or a,#0xd8
ld h,a
ld a,(_vtattr)
ld (hl),a
;-------------------
; +22b & 78t.
call videopos
;
; TODO: Map char 0x60 to a grave accent bitmap rather
; than fudging with a quote
;
ld b, #0 ; calculating offset in font table
ld a, c
cp #0x60
jr nz, nofiddle
ld a, #0x27
nofiddle:
or a ; clear carry
rla
rl b
rla
rl b
rla
rl b
ld c, a
ld hl, #0x3C00 ; ROM font
add hl, bc ; hl points to first byte of char data
; printing
ld c, #8
plot_char_loop:
ld a, (hl)
ld (de), a
inc hl ; next byte of char data
inc d ; next screen line
dec c
jr nz, plot_char_loop
ret
_clear_lines:
pop bc
pop hl
pop de ; E = line, D = count
push de
push hl
push bc
clear_next_line:
push de
ld d, #0 ; from the column #0
ld b, d ; b = 0
ld c, #32 ; clear 32 cols
push bc
push de
push af
call _clear_across
pop af
pop hl ; clear stack
pop hl
pop de
inc e
dec d
jr nz, clear_next_line
ret
_clear_across:
pop iy
pop hl
pop de ; DE = coords
pop bc ; C = count
push bc
push de
push hl
push iy
call videopos ; first pixel line of first character in DE
push de
pop hl ; copy to hl
xor a
; no boundary checks. Assuming that D + C < SCREEN_WIDTH
clear_line:
ld b, #8 ; 8 pixel lines to clear for this char
clear_char:
ld (de), a
inc d
dec b
jr nz, clear_char
ex de, hl
inc de
push de
pop hl
dec c
jr nz, clear_line
ret
copy_line:
; HL - source, DE - destination
; convert line coordinates to screen coordinates both for DE and HL
push de
ex de, hl
call videopos
ex de, hl
pop de
call videopos
ld c, #8
copy_line_nextchar:
push hl
push de
ld b, #32
copy_pixel_line:
ld a, (hl)
ld (de), a
inc e
inc l
dec b
jr nz, copy_pixel_line
pop de
pop hl
inc d
inc h
dec c
jr nz, copy_line_nextchar
ret
; TODO: the LDIR way should be much faster
_scroll_down:
; set HL = (0,22), DE = (0, 23)
xor a
ld d, a
ld h, a
ld l, #22
ld e, #23
ld c, #23 ; 23 lines to move
loop_scroll_down:
push hl
push de
push bc
call copy_line
pop bc
pop de
pop hl
dec l
dec e
dec c
jr nz, loop_scroll_down
ret
_scroll_up:
; set HL = (0,1), DE = (0, 0)
xor a
ld d, a
ld e, a
ld h, a
ld l, #1
ld c, #23 ; 23 lines to move
loop_scroll_up:
push hl
push de
push bc
call copy_line
pop bc
pop de
pop hl
inc l
inc e
dec c
jr nz, loop_scroll_up
ret
_cursor_on:
pop bc
pop hl
pop de
push de
push hl
push bc
ld (cursorpos), de
call videopos
ld a, #7
add a, d
ld d, a
ld a, #0xFF
ld (de), a
ret
_cursor_off:
ld de, (cursorpos)
call videopos
ld a, #7
add a, d
ld d, a
xor a
ld (de), a
ret
_do_beep: ; do 880Hz dure 1/8s
di
ld bc,#00fe
ld h,110
loop_beep1:
ld de,149
loop_beep:
dec de
ld a,d
or a,e
jr nz,loop_beep
ld a,l
cpl
ld l,a
and a,#10
out (c),a
dec h
jr nz,loop_beep1
ei
ret
_vtattr_notify: ; void vtattr_notify(void)
ld a,(_vtpaper)
rlca
rlca
rlca
and a,#0x78
ld c,a
ld a,(_vtink)
ld b,a
and a,#0x07
or a,c
ld c,a
ld a,b
rlca
rlca
rlca
and a,#0x40
or a,c
ld (_vtattr),a
ret
; --------------
; 27b.
.area _DATA
cursorpos:
.dw 0
Посмотрел мап-файл ядра, и возник вопрос: многие ли из тех, кто может запустить FUZIX, пользуются микродрайвом? :)
00004DA8 _mdv_motor_off microdrive
00004DB2 _mdv_motor_on microdrive
00004DBE _mdv_bread microdrive
00004DDB _mdv_bwrite microdrive
Посмотрел мап-файл ядра, и возник вопрос: многие ли из тех, кто может запустить FUZIX, пользуются микродрайвом? :)
00004DA8 _mdv_motor_off microdrive
00004DB2 _mdv_motor_on microdrive
00004DBE _mdv_bread microdrive
00004DDB _mdv_bwrite microdrive
Это была ключевая составляющая фузикса на ZX-48. Ядро воткнуть в слот расширения в РОМ-картридже, а задачи своппить на 8 микродрайвов. Переключение бы было адово медленным, но оно бы работало. Алан писал в бложик, что у него это всё даже работало, но сильно глючило, а разбираться ему уже стало лень.
Я почти допилил нормальную систему сборки ядра zx128, а парадигме скриптов из /Build. С ней можно будет запилить отдельные конфиги для ZX-128 (микродрайв и DISCiPLE), Pentagon (Betadisk), TS-Conf etc, собирая только те модули, которые нужны.
Я почти допилил нормальную систему сборки ядра zx128, а парадигме скриптов из /Build. С ней можно будет запилить отдельные конфиги для ZX-128 (микродрайв и DISCiPLE), Pentagon (Betadisk), TS-Conf etc, собирая только те модули, которые нужны.
Это просто замечательно!
К сожалению, собственные попытки вникнуть во все взаимосвязи модулей фузикса представляются мне бесперспективными, но я готов написать весь необходимый код для использования всех возможностей тсконфы.
Программа минимум:
- своп нижней памяти процессов не копированием банок, а переключением страниц через порт -0x12af;
- копирование контекста (стэка и т.п.) средствами ПДП.
Программа максимум - вынести ядро за пределы адресного пространства, освободив для программ более 48кБ.
Покамест, хакнул твой последний снапшот: добавил полноценный шрифт от CLI2 (прехватываю инициализацию шрифта. Доп. код размещён на месте подпрограмм, обслуживающих микродрайв).
Error404
14.09.2017, 00:06
Кто-нибудь в курсе, как там дела с FUZIX - TCPIP фунциклирующий они таки уже родили или еще нет? А то пятилетка уже к концу, а взятые повышенные обязательства пока всё никак. :)
Хочу поделиться - очень прикольная тема: прокси, рендерящий современные тяжеловесные страницы в GIF/JPEG-картинку с пиксель-привязанной картой кликабельных ссылок из оригинальных страниц. Кто там хотел браузер на Спеке? uIP на Z80 уже портирован { таки придется, ведь "это вам не это"(с) }, ставите этот прокси на арендованной виртуалке (PC с Mac OS X или Linux), пишете простого html-клиента, и вуаля.
https://github.com/tenox7/wrp
Народ в восторге, браузят древнючими браузерами первого html 30-летней давности с Амиг и прочего антиквариата.
- - - Добавлено - - -
На древнем UZIX от MSX по точно таком принципу работал браузер FudeBrowser - через прокси, хостящейся в Инете (UZIX вообще был куда как более продвинут относительно UZI/FUZIX, я до сих пор не понимаю почему для FUZIX образцом не взяли UZIX). Но тот прокси от UZIX был куда как более примитивен с одной стороны, т.к. корежил исходное форматирование, но с другой - более сложен, т.к. не просто гнал картинку, а делал некий переформатированный гипертекстовый вывод (что впрочем требовало более сложного клиента-браузера на MSX).
CityAceE
14.09.2017, 02:43
https://github.com/tenox7/wrp
Да оно ещё и на Питоне! Супер! Люблю Питон ;)
Error404
09.10.2018, 10:25
Подскажите, знающие люди, есть ли в природе репозитории с бинарями для FUZIX под какие-нибудь платформы? Желательно обновляющиеся, ну или достаточно свежие. Хочу в UZIX сделать выполнение бинарей из FUZIX через "прокладку" (как это там же работает с исполнением бинарей от CP/M).
Подскажите, знающие люди, есть ли в природе репозитории с бинарями для FUZIX под какие-нибудь платформы?
Необновляемый и не репо, но наковырять бинарей из образа можно - http://www.fuzix.org/
Кстати, буквально на днях в fuzix появилась поддержка релоцируемых бинарей для z80. Это даёт надежду на бинарную совместимость между "нормальными" z80-машинами с RAM в нижней памяти и спектрумом, где из-за ROM адрес загрузки программ смещен вверх.
Error404
09.10.2018, 13:01
Необновляемый и не репо, но наковырять бинарей из образа можно - http://www.fuzix.org/
Тогда еще спрошу: нет ли еще готовой ucp.exe под Винду для расковыривания этих образов? Очень не хочется заморачиваться с компиляцией, а аналогичная от UZIX думаю не подойдет (т.к. Алан увеличил длину имен файлов на 2 символа в сравнении с UZI/UZIX {facepalm} ).
Тогда еще спрошу: нет ли еще готовой ucp.exe под Винду для расковыривания этих образов?
Собрал под cygwin: https://www.dropbox.com/s/jh49svmwswbv9zi/ucp.zip?dl=0
Вобщем для fuzix нужен такой комп: http://sowerbutts.com/socz80/
Но fuzix пока еще не поддерживает для него езернет: https://github.com/EtchedPixels/FUZIX/tree/master/Kernel/platform-socz80
Если подключить к socz80 zxnetusb ?
Вести с полей: нашелся храбрец, который смог собрать версию под ZX Spectrum 128K + DivIDE и запустить. Краткая инструкция и бинари для желающих повторить в теме https://github.com/EtchedPixels/FUZIX/issues/756
Error404
07.11.2019, 01:16
Вести с полей: нашелся храбрец, который смог собрать версию под ZX Spectrum 128K + DivIDE и запустить. Краткая инструкция и бинари для желающих повторить в теме https://github.com/EtchedPixels/FUZIX/issues/756
Столько труда чтобы 2/3 команд выдавали "Out of memory". Сразу было понятно, что надо искать другую модель чем где процессы не более 16к. При наличии быстрого нoсителя (IDE) даже классический UZI где каждый процесс при переключении выгружается, и то более пригоден, на MSX работали же в такой архитектуре. Хотя конечно, просто нужно нормальное окно диспетчера. Чего уж не впилить пару МСХ, что-то религиозное что ли, типа как носить вериги?
Столько труда чтобы 2/3 команд выдавали "Out of memory". Сразу было понятно, что надо искать другую модель чем где процессы не более 16к. При наличии быстрого нoсителя (IDE) даже классический UZI где каждый процесс при переключении выгружается, и то более пригоден, на MSX работали же в такой архитектуре.
Там 32 кило на процесс (учитывая три страницы под ядро и одну под экран и низкоуровневые процедуры, остатка нам хватает на целых 2 процесса). Процессор LDIRится так, что дым идёт. Ну, по крайней мере так было в v0.2.
Это я в первоначальном порте делал для процессов 7 окон по 16 кило, но Алан с тех пор много перепилил. Он между 0.2 и 0.3 очень много для спектрума там делал.
Хотя конечно, просто нужно нормальное окно диспетчера. Чего уж не впилить пару МСХ, что-то религиозное что ли, типа как носить вериги?
Сточить ULA и припаяться к транзисторам? :) Или делать картридж с RAM, который будет содержать нужный маппер? Если считать, что таргет-платформа - это не обмотанный мгтфом пентагон, а классический спек, то все решения по добавлению маппинга выглядят как жуткие костыли. Ну и в целом, софт без железа (ну то есть не работающий из коробки) - это ничуть не лучше популярного у нас на форуме подхода "железо без софта". Фузих должен работать на любом спектруме, чтобы охватить максимальную аудиторию. В идеале он вообще с кассеты должен уметь грузиться :D
Но! На самом деле тот маппер, о котором ты говоришь, он уже поддержан. Причем, уже лет пять: https://github.com/EtchedPixels/FUZIX/blob/master/Kernel/bank16k.c
То есть если кто-то захочет-таки сделать хардварную доработку, он просто заменит текущий маппер (https://github.com/EtchedPixels/FUZIX/blob/master/Kernel/dev/zx/bank128.c) на новый, ну и допишет немного кода переключения. Это ж ерунда по сравнению с необходимостью резать дорожки и клеить дохлых тараканов.
В порте для пентевы именно этот маппер и использован - https://github.com/EtchedPixels/FUZIX/blob/master/Kernel/platform-zxevo/fuzix.lnk#L37
Да, кстати, если кто не следит (будто кто-то следит :) ), Алан запилил отдельную платформу для евы (https://github.com/EtchedPixels/FUZIX/tree/master/Kernel/platform-zxevo)! Только для бейзы, но в коммитах у него там встречались рассуждения и про тсконф. Сидит, значит, в Уэльсе мужик, хреначит софт под российские клоны. Даже стыдно немного.
CodeMaster
07.11.2019, 07:56
Да, кстати, если кто не следит (будто кто-то следит ), Алан запилил отдельную платформу для евы!
До такой степени конечно нет, но эту тему почитываем, т.ч. релизь новости здесь.
Error404
07.11.2019, 12:05
Там 32 кило на процесс (учитывая три страницы под ядро и одну под экран и низкоуровневые процедуры, остатка нам хватает на целых 2 процесса). Процессор LDIRится так, что дым идёт. Ну, по крайней мере так было в v0.2.
В таком варианте уже как-то можно жить. Один хрен, под большие вещи типа VI не хватает и 60к (ибо большое не значит хорошее как оказалось при ближайшем рассмотрении).
- - - Добавлено - - -
Сидит, значит, в Уэльсе мужик, хреначит софт под российские клоны. Даже стыдно немного.
Просто как оказалось, никому кроме 2-3 чудаков оно не надо.
- - - Добавлено - - -
Хомячков оно могло привлечь в виде UZIX где был нормальный TCP/IP, а не обрубок от uIP как в FUZIX, и можно было даже с учетом того что от него утрачены исходники провести реверс (учитывая какие человекочасы уже затрачены на FUZIX, зачастую имея на выходе нечто более негодное).
обрубок от uIP как в FUZIX
Эммм, откуда инфа? Сокеты как сокеты, где там обрубок, тем более uIP?
Error404
07.11.2019, 15:11
Эммм, откуда инфа? Сокеты как сокеты, где там обрубок, тем более uIP?
Так там вроде никогда другого и не было? Был обрубок uIP Дункеля, причем прикрученный не в ядро а как-то сбоку. Ну если не считать первых заглушек для программирования верхних уровней стека без наличия нижних. По крайней мере полгода-год назад когда я еще находл в себе силы перекапывать эту слабоструктурированную кучу-малу. Если переписали, то интересно как (не слышал что для 8-биток родили какие-то новые реализации стека в последние год-два). А если нет, и на уровень хидеров выведено нечто а-ля сокеты, уже неинтересно если унутре по-прежнему оно (наелся я этого uIP в свое время, плевались все кому надо было что-то чуть более сложное чем веб-сервер из примеров Дункеля или Контики где оно интегрировано и всё уже написано самим автором).
А обрубок (помимо дикой упрощенности uIP в ущерб функционалу и производительности), потому что IP должен быть в ядре (чего у них не было сделано), а не в либе целиком. Чтобы процессы читая сокет блокируемо или неблокируемо, по этому типу ядром автоматом переводились в саспенд освобождая слайсы ЦПУ, или будились (доставались из свапа) при поступлении данных. А так как было сделано, так это я и сейчас могу прилинковать либу uIP прямо в приложение, благо порт есть, но это совсем не то чего хотелось бы. А нет, не могу, начну писать код под uIP и затошнит. :)
- - - Добавлено - - -
Это остаточные знания. С интервалом раз в год поглядываю в исходнике на ГИТ как там дело движется с TCP/IP т.к. это единственное что всерьез интересует меня в том проекте на предмет портануть в UZIX, каждый раз дико матерясь т.к. этот модуль лежит как-то хрен сразу найдешь. И в последний раз с год назад там все еще был код от uIP (я его хорошо знаю т.к. портировал на Орион, да и копирайты нам все на месте) и никакого другого я ни разу не нашел (если не считать версию от 2015 года где был только скелет верхних уровней стека с каким-то дурным роутером в PC вместо реализации собственно IP). Сейчас снова полез уточнить, вдруг переписали и убрали uIP, и снова по-быстрому не нахожу там где по логике расчитывал этот модуль найти (постоянная история), чтоб их так перетак.
снова по-быстрому не нахожу там где по логике расчитывал этот модуль найти (постоянная история), чтоб их так перетак
Имея информацию, что оно там не совсем в ядре, я сходу нашёл: FUZIX/Applications/netd
В ядре только драйвера устройств.
Так там вроде никогда другого и не было?
По факту там обычные сокеты - bind, listen, connect, recvfrom и т.д. (https://github.com/EtchedPixels/FUZIX/blob/master/Kernel/include/netdev.h#L102)
Был обрубок uIP Дункеля, причем прикрученный не в ядро а как-то сбоку.
Всё, я понял. Ты об этом, наверное - https://sites.google.com/site/cocoboot2/fuzix/fuzixworkingthecoconiccard
Автор этого дела сам пишет, что это слепленный за вечер хак и что он всё сделает нормально, когда разберется, как писать сетевые драйверы.
Пока ещё не сделал. Вот этот хак - https://github.com/EtchedPixels/FUZIX/blob/master/Applications/netd/netd.c
И со стороны ядра фальшивый драйвер сетевого интерфейса - https://github.com/EtchedPixels/FUZIX/blob/afa5791cdd85c750968334b6c9fbe436df814543/Kernel/dev/net/net_native.c
Довольно изящно, кстати
А нет, не могу, начну писать код под uIP и затошнит.
Изящно потому, что не нужно писать под uIP. Крутится там себе где-то, и бог с ним. Код под fuzix работает только с сокетами и знать ничего про uIP не знает.
Ну и не стоит думать, что это единственный способ сетевого взаимодействия. Можно не тянуть себе в систему весь этот uIP, а делать всё через "настоящие" драйверы, которые есть, к примеру, для W5x00 и ENC28J60. Всё тут: https://github.com/EtchedPixels/FUZIX/tree/master/Kernel/dev/net
Error404
08.11.2019, 01:11
Можно не тянуть себе в систему весь этот uIP, а делать всё через "настоящие" драйверы, которые есть, к примеру, для W5x00 и ENC28J60. Всё тут: https://github.com/EtchedPixels/FUZIX/tree/master/Kernel/dev/net
Без uIP наверное можно использовать Визнеты (у них стек реализован внутри контроллера), но для ENC28J60 таки нужно что-то вроде uIP, т.к. ENC28J60 это только модуль MAC/PHY.
Было бы здорово если затянуть в ядро lwIP, но для него надо несколько 64к страниц. Зато это полнофункциональный стек со сборкой кадров, т.е. там не будет ограничения скорости в 6 кб/c и буфера приема в 1.5кб как у uIP и ему подобных, где для упрощения пакет всегда равен одному кадру.
nihirash
08.11.2019, 02:34
Без uIP наверное можно использовать Визнеты (у них стек реализован внутри контроллера)
Или сделать драйвер для ESP-8266 - тот тоже может быть аппаратным TCP-стеком.
Да и, на самом деле, особо больше, чем uIP и не требуется на таких мощностях.
Или сделать драйвер для ESP-8266 - тот тоже может быть аппаратным TCP-стеком.
Оно практически уже есть - сокеты через AT-команды. Не уверен, что совместимо с соответствующей прошивкой для ESP, но всё равно уже очень близко.
https://github.com/EtchedPixels/FUZIX/blob/master/Kernel/dev/net/net_at.c
Без uIP наверное можно использовать Визнеты (у них стек реализован внутри контроллера), но для ENC28J60 таки нужно что-то вроде uIP, т.к. ENC28J60 это только модуль MAC/PHY.
Да, пардон, ENC28J60 там не в виде готового драйвера, а просто какая-то заготовка. И в единственной платформе, где оно используется, работа действительно идет через net-native, т.е. через uIP.
nihirash
08.11.2019, 10:40
Оно практически уже есть - сокеты через AT-команды. Не уверен, что совместимо с соответствующей прошивкой для ESP, но всё равно уже очень близко.
https://github.com/EtchedPixels/FUZIX/blob/master/Kernel/dev/net/net_at.c
Ну это совсем куцый вариант. Нормальная фирмварь для esp-ши может в 4тсокета одновременно, они могут быть как TCP, так и UDP, как исходящие, так и принимающие.
Чего для сетевого софта под такие машины имхо достаточно.
Error404
08.11.2019, 15:12
Ну это совсем куцый вариант. Нормальная фирмварь для esp-ши может в 4тсокета одновременно, они могут быть как TCP, так и UDP, как исходящие, так и принимающие.
Чего для сетевого софта под такие машины имхо достаточно.
У варианта с ESP не хватает одного - нормального интерфейса к ESP с хоста. RS-232 так себе решение (которое к тому же мало где есть "из коробки"), и если уж для подключения чего-то городить, то тогда лучше подошел бы на 2 порядка более быстрый SPI. Да вот беда, чтобы ESP, имеющее SPI, умело через него общаться (а не тупо подключать слейвы), нужно перепиленное фирмваре ESP. SFS такое начинал делать пару лет тому назад, но видимо бросил, а жаль.
https://pluspora.com/p/2463796
Алан Кокс заявил, что до пенсионного возраста дожить нереально, поэтому он собрался на пенсию прямо сейчас, с 1 января. Будет писать фузикс и наслаждаться жизнью.
SFS такое начинал делать пару лет тому назад, но видимо бросил, а жаль.
Я начинал делать с RS232. И бросил, потому что понял: без прерываний от компорта на спеке получается гумно.
ИМХО, надо идти другим путём.
Возможно сделать "сетевуху" из ESP8266 под слот NEMOBUS, которая будет общаться со спеком по DMA и генерировать прерывания. Прошивка ESP8266, конечно нужна будет не стандартная, но это не проблема.
По сути вся эта "сетевуха" - ESP8266 плюс регистры и формирователи.
Тогда со скоростью будет всё хорошо и не будет дурных циклов ожидания.
Кстати, мои эксперименты с ESP8266 не пропали даром. Вот что вышло: https://shiotiny.ru/ (правда, к спектруму это отношения не имеет).
sergio78
02.01.2020, 17:18
Алан Кокс заявил, что до пенсионного возраста дожить нереально
он это, точно не из россии? что то прям именно про нашу страну один в один говорит.
NEO SPECTRUMAN
02.01.2020, 17:39
из россии?
Алан Кокс заявил, что до пенсионного возраста дожить нереально, поэтому он собрался на пенсию прямо сейчас, с 1 января. Будет писать фузикс и наслаждаться жизнью.
взаимоисключающие параграфы
sergio78
02.01.2020, 22:27
взаимоисключающие параграфы
че это? в рф с барского стола тоже в некоторых местах хорошие печеньки капают. можно в москве накупить квартир и сдавать их, соответственно уйдя на добровольную пенсию.
NEO SPECTRUMAN
02.01.2020, 22:51
можно в москве накупить квартир и сдавать их, соответственно уйдя на добровольную пенсию.
а место еще не занято?
а потом окажется что безболезненно сдавать квартиры могут только свои :)
он это, точно не из россии? что то прям именно про нашу страну один в один говорит.
Всё ещё продолжаешь наивно верить что там лучше? :v2_dizzy_biggrin2:
NEO SPECTRUMAN
03.01.2020, 07:15
а там и так лучше
просто там свои приколы...
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot