Блог страдающего Лиса
Lorem ipsum hello dolor sit world amet
16 ноя 2024 Сб
Новое веяние графического построения
Наконец-то у меня появилась возможность просто взять и сделать программу, которая бы рисовала кодом, а не это вот все. Теперь я могу просто брать и в своей админке проверять то, что не мог проверять раньше, а именно нарисовать например, вот таким кодом:
Причем совершенно невозбранно. Это классно, ведь теперь есть возможность быстро рисовать и проверять кодом и загружать картинки вот сюда в блог и не только. Раньше мне приходилось очень сложно и много рисовать в Quick Basic, но эти времена ушли и стали наступать новые, более интересные времена.
Еще у меня есть микросхема EPM240 и я отчаянно пытаюсь придумать ей применение. Один из вариантов, сделать для нее подключение к микросхеме памяти и юзать на полную катушку. С другой стороны, надо бы придумать что-то поинтереснее, чем просто создавать одно и то же постоянно. Самым удобным методом было бы конечно, загрузить программу в SRAM и там исполнять ее, но проблема в том, что эта SRAM работает срамно медленно. Ну вот если посудить, то чтобы запросить один байт памяти, требуется отослать 8 бит команду, 16 бит адреса и 8 бит данных (чтение или запись). Медленно, крайне медленно, даже если запускать на 12.5 мгц, то это скорость 390625 байт в секунду. Для сравнения, спектрум читал 875000 байт в секунду, что быстрее в 2.24 раза.
С другой стороны, если отбросить все умозаключения и страдания из-за скорости, то что меня парит? 381кб в секунду это не прямо настолько мало, чтобы совсем ничего не делать. Но проблема еще в том, что графику надо бы где-то отображать... То есть, если еще и читать из этой памяти графику, то скорость работы процессора вообще будет невероятно медленной.
Итак, представим что надо отобразить экран 256 на 192, это значит что придется запрашивать на скорости 12.5 мгц, а значит что эффективных тактов будет 256/400, так как строк по ширине у VGA для разрешение 640 на 400 будет равно 800. Итак, это дает 64% загрузки, остается лишь 4.5 чтения из памяти на один сканлайн.
Хорошо, это слишком медленно и представим что мы следуюший сканлайн вообще выводить не будем. Это дает 400 тактов / 32 = 12.5 чтений или записей на 1 линию. Итого, на две линии будет суммарно около 17 чтений или записи. Всего строк 192, а значит, 3264 байт на кадр. Помимо 192 строк, остаются свободными 65 строк на гашение кадра и прочей лабуды. Это дает 65*12.5 = 812 байт на кадр.
Итого 4076 байт на кадр или 4076x60 = 244560 байт в секунду, 238Кб в секунду. На самом деле, это не так плохо! 40% падения производительности с пропуском сканлайнов.
И получится то, что можно с последовательной SRAM выводить как графическое изображение, так и выполнять код одновременно с выводом, что очень неплохо. Надо теперь подумать, как бы реализовать такую минималистичную систему и процессор для этого дела. Ведь количество LE крайне ограничено. Смогу ли я вообще сделать в таком небольшом объеме хоть что либо? Кто знает.
cls(); let cat = "CAT on THE KittyCat"; for (let i = 1; i < 100; i++) circle(160,100,i,clr(i)); print(cat,86,11,clr(15)); print(cat,85,10,clr(0));И при этом получиться такая вот картинка.
Причем совершенно невозбранно. Это классно, ведь теперь есть возможность быстро рисовать и проверять кодом и загружать картинки вот сюда в блог и не только. Раньше мне приходилось очень сложно и много рисовать в Quick Basic, но эти времена ушли и стали наступать новые, более интересные времена.
Еще у меня есть микросхема EPM240 и я отчаянно пытаюсь придумать ей применение. Один из вариантов, сделать для нее подключение к микросхеме памяти и юзать на полную катушку. С другой стороны, надо бы придумать что-то поинтереснее, чем просто создавать одно и то же постоянно. Самым удобным методом было бы конечно, загрузить программу в SRAM и там исполнять ее, но проблема в том, что эта SRAM работает срамно медленно. Ну вот если посудить, то чтобы запросить один байт памяти, требуется отослать 8 бит команду, 16 бит адреса и 8 бит данных (чтение или запись). Медленно, крайне медленно, даже если запускать на 12.5 мгц, то это скорость 390625 байт в секунду. Для сравнения, спектрум читал 875000 байт в секунду, что быстрее в 2.24 раза.
С другой стороны, если отбросить все умозаключения и страдания из-за скорости, то что меня парит? 381кб в секунду это не прямо настолько мало, чтобы совсем ничего не делать. Но проблема еще в том, что графику надо бы где-то отображать... То есть, если еще и читать из этой памяти графику, то скорость работы процессора вообще будет невероятно медленной.
Итак, представим что надо отобразить экран 256 на 192, это значит что придется запрашивать на скорости 12.5 мгц, а значит что эффективных тактов будет 256/400, так как строк по ширине у VGA для разрешение 640 на 400 будет равно 800. Итак, это дает 64% загрузки, остается лишь 4.5 чтения из памяти на один сканлайн.
Хорошо, это слишком медленно и представим что мы следуюший сканлайн вообще выводить не будем. Это дает 400 тактов / 32 = 12.5 чтений или записей на 1 линию. Итого, на две линии будет суммарно около 17 чтений или записи. Всего строк 192, а значит, 3264 байт на кадр. Помимо 192 строк, остаются свободными 65 строк на гашение кадра и прочей лабуды. Это дает 65*12.5 = 812 байт на кадр.
Итого 4076 байт на кадр или 4076x60 = 244560 байт в секунду, 238Кб в секунду. На самом деле, это не так плохо! 40% падения производительности с пропуском сканлайнов.
И получится то, что можно с последовательной SRAM выводить как графическое изображение, так и выполнять код одновременно с выводом, что очень неплохо. Надо теперь подумать, как бы реализовать такую минималистичную систему и процессор для этого дела. Ведь количество LE крайне ограничено. Смогу ли я вообще сделать в таком небольшом объеме хоть что либо? Кто знает.