Проверить можно так.
1. Берем ОПТС 2. Грузим файл с магнитофона, но не запускаем.
2. Сохраняем файл на магнитофон.
3. Берем ОПТС 1. Грузим полученный на шаге 2 файл.
Вид для печати
Проверить можно так.
1. Берем ОПТС 2. Грузим файл с магнитофона, но не запускаем.
2. Сохраняем файл на магнитофон.
3. Берем ОПТС 1. Грузим полученный на шаге 2 файл.
С синтаксисом в п.2 напутано, там надо адреса еще указывать. Попробуйте методом научного тыка, я сейчас все равно не вспомню.
мысль какая - скорее всего период сигнала msxcas для 2.0 входит в допустимый предел, а для 1.1. - нет. А так хотя бы можн проверить совместимы ли вообще по форматам эти версии.
Короче, сохранил я в бейсике 2.0 на магнитофон простенькую программу на 2 строчки,
и в бейсике 1.1 без проблем её загрузил.
Вывод, что-то Ваш, marinovsoft, конвертер не так делает. Хотя бейсик 2.0 понимает.
99,9% что проблема с периодом. Корвета 1.1 нет и не предвидется.
Код:Const
Arr1:Array[1..8] Of Byte=($1,$2,$4,$8,$10,$20,$40,$80);
Const
Bit1 : Array[1..36] Of Integer =
(-5000,-5000,-5000,-5000,-5000,-5000,-5000,-5000,-5000,
5000, 5000, 5000, 5000, 5000, 5000, 5000, 5000, 5000,
-5000,-5000,-5000,-5000,-5000,-5000,-5000,-5000,-5000,
5000, 5000, 5000, 5000, 5000, 5000, 5000, 5000, 5000);
Bit0 : Array[1..36] Of Integer =
(-5000,-5000,-5000,-5000,-5000,-5000,-5000,-5000,-5000,
-5000,-5000,-5000,-5000,-5000,-5000,-5000,-5000,-5000,
5000, 5000, 5000, 5000, 5000, 5000, 5000, 5000, 5000,
5000, 5000, 5000, 5000, 5000, 5000, 5000, 5000, 5000);
Procedure Write_bit_1;
begin
BlockWrite(_RAWFile,Bit1,SizeOf(Bit1));
end;
Procedure Write_bit_0;
begin
BlockWrite(_RAWFile,Bit0,SizeOf(Bit0));
end;
Блин, замешкался. Я записал и опять считал в бейсике 2.0.
Ща попробовал загрузить в бейсике 1.1.
Появляется "ЗАГРУЗКА ФАЙЛА 123" и всё. Дальше не грузится.
Но хоть заголовок читает.
Мечты сбываются однако! Работает загрузка с KDI-образов на SD-карте! Пока всё очень сырое: нет возможности выбрать образ, нет выбора дисков A или B и т.д. Пока реализовано с применением обкатанного много раз мной SoftCore Plasma (немного кастрированный процессор MIPS R2000). Зато потенциаль какой! 8Мб SDRAM в моём распоряжении. В конце концов я всё равно переведу эмуляцию дисковода, наверное, на Z80.
Время будет, немного подробнее опишу как и что. Сейчас руки чешуться попробовать софта побольше!
Появилась идея у меня,
я, наверное, сделаю эмуляцию дисковода на VHDL а образы дисков
будут читаться из FLASH на DE1. Так как ПЗУ, FontROM и маппер не
вмещаются во внутреннюю память FPGA, то ПЗУ я храню во FLASH.
Ну а раз людям, решившим самим "пощупать" корвет на DE1 всё равно
придётся прошивать флэш, то за одно можно туда же и пару KDI-образов
прошить. Соберу туда самые интересные игрушки, а их не так уж и
много, и приложу файл к проекту. Переключать образы стандартным
способом можно будет, A:, B: и т.д.
Так я приведу мой проект в более или менее юзабельный вид. Просто
времени у меня на моё творчество не много осталось. Дел недоделанных
поднакопилось уйма. Надо будет сделать паузу. И за одно получится
урезанная корка ВГ93 на VHDL! Может кому она понадобится.
Плохо напрягать пользователя прошивкой флеша на DE1. Это когда разрабатываешь кажется, что невелик напряг прошить флеш, потому что по сравнению с разработкой это действительно не напряг ни разу. А когда ты играешься с чужими проектами, напряг оказывается велик и мотивация смотреть на такой проект сразу падает. Тем более, если во флеше уже что-то другое (например, куски OCM, как у меня). Не получается сделать начальный загрузчик с SD, который работает на том же процессоре, всасывает биос из какого-то предопределенного файла в рутовом каталоге и, затем, делает какой-то магический пас по которому самоуничтожается?
У меня всего одна проблема, это нехватка M4K памяти у циклона.
Всего около 8кбайт свободно, и выкинуть нечего. Всё нужно.
Тоесть, если уложиться в 8Кб кода, тогда без проблем. Но есть одно но!
Моих знаний ассемблера на это не хватит, а писать на си, код получится,
я думаю, больше. Хотя попробовать можно.
А почему нельзя выкинуть? Это ПЗУ, или ОЗУ? Если ПЗУ, то их можно считать с той же SD. Загрузчик как раз эту проблему и должен решить. Но и в 8К он должен прекрасно поместиться.
Не знаю, может быть tiny fatfs можно скомпилировать BDS C? Чем еще компилируют C для 8080 — когда я интересовался, никакого ответа я не нашел. В моей БК для этого используется ее же родной vm1, благо для него целых два компилятора есть. Может быть можно попробовать его выдрать и заставить работать загрузчиком :)
Напрямую tinyFATfs BDS C не скомпилит. Уж очень он не стандартный, даже не K&R. А вот сделать порт под BDS - имхо вполне. Причём, если ориентироваться на 80ю корку, то как раз BDS ИМХО-самое то в смысле компактности сгенерённого кода. Ещё пришло на ум предложить посмотреть на C цомпилер, написанный vinxru. Он, вроде стандартный x3.169, если даже не выше.
Ну, тут я свободен в выборе! Можно использовать, например, ZPU. Или какой нибудь другой SoftCore, под который полноценный GCC имеется. На OpenCores есть несколько AVR-корочек. Правда я пока не пробовал ни одной из них. Места в FPGA ещё уйма, только с M4K напряг.
На странице ElmChan написано, что TinyFATfs занимает около 4кб. В таком случае шансов много!
Заменил FatFS на Petit FatFS, отключил запись и...
Проект занял всего 5кб кода! И это для MIPS с 32-битными инструкциями!
Не ожидал! Есть надежды, что всё получится!
Еще много места остается. Загрузчик для bk0010 занимает 8кБ, причем это скомпилированный адским древним pcc. GCC может быть был бы компактней, хотя кто его знает. Там тоже le petit fatfs + то да се, там даже printf() есть.
А что за MIPS ты используешь и сколько ресурсов он сам занимает?
ILoveSpeccy, немного оффтопик.... А машинки с реальным MIPS'ом (например, SGI-шного чего-нить) у вас случаем нет? Или может быть опыт работы с такими машинами есть?
Я использую процессор mlite из проекта Plasma (на opencores.org).
32-бинтый MIPS R2000 совместимый (все команды, кроме "unaligned load/stores" и exceprions). 1 такт на 1 команду. 1.25DMIPS/MHz. Производительность на высоте!
На моём сайте есть собранные GCC (C,C++) с библиотеками (newlib) под windows и linux.
Само ядро занимает примерно 2000LE's во втором циклоне (de1). Тоесть, примерно как T80, только производительность в 50 раз (может ещё выше, не сравнивал) выше, при той же частоте.
Зато сравнивал с ATMEGA64, затактованным на 20MHz. Короче ATMEGA делает 6.5DMIPS (~0.33 DMIPS/MHz). Тоесть по тесту DHRYSTONE plasma быстрее, чем мега в 4 раза, при той же частоте.
---------- Post added at 21:24 ---------- Previous post was at 21:21 ----------
Не, даже в глаза не видел! Я с архитектурой MIPS познакомился во время знакомства с "плазмой". Заказал книгу из штатов и немного проштудировал как там и что. Интересная архитектура, ассемблер приятный. Ну и полноценная поддержка со стороны GCC. Чего ещё надо? :)
Догнал эмуляцию дисковёрта до достаточно безглючного состояния. Теперь всё, что пробовал, грузится и работает. Пришлось быстренько сварганить тестовую платку с PIC24 и SD-картой, так как не мог выловить кой какие глюки. Казалось дело было в softcore, а оказалось , как это часто бывает, банальная невнимательность.
Теперь вопрос к знатокам! как мне привязать свой дисковёрт к корвету так, чтобы стандартными методами можно было выводить список образов с карты и выбирать нужный. В лучшем случае прямо из бейсика или cp/m, без использования других ромов. Можно ли доработать стандартный?
Подобное, например, сделано в эмуляторе дисковода MMC2IEC для C64.
ROM бейсик - про существование дисковода и не догадывается
если логика контроллера своя - то как вариант можно сделать спец работу с например 255 дорожкой (на реальных дисках не бывает)
типа читаем из 255/01 - получаем 1к названий образов
пишем имя образа и номер диска в 255/01 - выбираем какой образ выбрать
Да, со стороны "железа" это довольно просто реализовать. И контроллеру программу доделать не составит труда мне. Что я сам не осилю, так это программную поддержку со стороны корвета. Если кто нибудь смог бы мне помочь в этом, то я доведу проект до своего логического завершения. Могу "допилить" эмулятор Сергея, чтобы эмулировался мой контроллер дисковода. Тогда отладить можно будет в эмуляторе. А к железу я прикручу...
будет эмулятор - написать тулзу не сильно сложно
попробую написать
Займусь эмулятором...
Давно новостей от меня не было.
Последние месяцы занимался разводкой, пайкой и сборкой девайса, на котором со вчерашнего дня "тикает" мой корвет.
Всю информацию о девайсе: схемы, плату, прошивки и т.д. постораюсь как можно быстрее выложить у себя на сайте.
Накалякал краткое описание проекта и выложил пару фоток, схему и рисунки платы.
Всё тут: http://speccyland.net/
Пока плата нового Aeon на производстве, я нашел всётаки немного время и довёл до рабочего состояния bootloader с SD-карточки. А это значит, что теперь можно доделать корвет на DE1. Программа для работы с образами, эмуляцией дисковода и пр. может грузиться с карты в SDRAM. Теперь всё ограничевается только фантазией, так как у нас в распоряжении 8 мегабайт.
Например, сам bootloader занял всего 4473 байта. И это для 32-битного MIPS процессора с полной поддержкой SD/SDHC карт и файловой системы FAT12/16/32.
На днях постораюсь склепать первую рабочую версию для DE1. Нужна будет только карта, на которую закидываются firmware, образы FONT, ROM и дисков. Карту в DE1, и enjoy!
По-поводу приобритения девайса обращаться сюда:
http://zx-pk.ru/market/viewtopic.php?f=7&t=2131
Может и зря поднимаю старую тему. Нужен совет опытных схемотехников.
В Корвете видеопамять реализована весьма специфическим образом. Запись и чтение по раздельным входам и выходам. Но это не главная заморочка. Главное - запись происходит по маске отдельно в каждую микросхему памяти. А они там однобитные РУ6(РУ5). Если маска позволяет - инициируется сигнал разрешения записи и в соответствующую ячейку соответствующего чипа происходит запись. Если маска не позволяет - сохраняется предыдущее состояние. Вопрос: как реализовать все это не на 24 РУ5, а на 3 61512, например. Только предварительно считав содержимое в регистр? Нет ли более простого решения? Если я что-то не понял в схеме - поправьте.
Если там запись реализована так, как вы описали, то только через read-modify-write
Да, интересный ты нюанс затронул. И важный! Действительно, на обычной статике такого не реализовать без RMW... Да и "необычной" такой статики (с маской) вроде бы нет...
Поэтому совет: реализовывать ГЗУ (а также и АЦЗУ) на внутренней памяти FPGA (причем и конфигурить её как двухпортовую - для беспроблемного видеовыхлопа). То есть 1 страница (4, если памяти дох....) х 3 плоскости х 8 разрядов (здесь маску и замутить) х (16К х 1).
LeoN65816, проблема в том, что не хочу FPGA. Хочется странного - CPLD :rolleyes: и железного проца, чипсета...
CPLD - сильно урезанный младший брат FPGA (точнее, FPGA - это развитие CPLD). В CPLD ограниченное количество внутренних связей (на простых проектах это не сказывается, а на серьёзных приводит в тупик), отсутствует внутренняя память, малое количество логических элементов.
Ну, и по железному процу - никто не заставляет тебя юзать софтядро, юзай натуральный чип.
Взгляни на семейства Flex10K и Acex1K.
LeoN65816, есть над чем подумать.
Народ, а у кого нибудь остались файлы от проекта. А то speccyland.net похоже умер уже давно.
А, все нашел, теперь все гитхабе - https://github.com/ILoveSpeccy/Aeon-Lite