nedoPC.org

Electronics hobbyists community established in 2002
Atom Feed | View unanswered posts | View active topics It is currently 28 Mar 2024 05:39



Reply to topic  [ 29 posts ]  Go to page 1, 2  Next
Судьба эмулятора SPRINT - теперь он называется SprintEm 

Какое железо ещё поддержать в этом эмуляторе?
ZX-Spectrum 48K/128K 10%  10%  [ 1 ]
ATM-Turbo2+ 10%  10%  [ 1 ]
Орион на Z80 10%  10%  [ 1 ]
Специалист на Z80 30%  30%  [ 3 ]
Никакое - пусть остаётся только Спринтер 10%  10%  [ 1 ]
А мне пофиг 30%  30%  [ 3 ]
Total votes : 10

Судьба эмулятора SPRINT - теперь он называется SprintEm 
Author Message
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22409
Location: Silicon Valley
Reply with quote
Задумался я тут над судьбой своего эмулятора Спринтера...

P.S. Добавил голосовалку 1 июня 2013 года

P.P.S. С лета 2018 года исходники эмуля живут на гитлабе, а с марта 2022 эмулятор стал называться SprintEm:

https://gitlab.com/nedopc/sprintem

_________________
:dj: https://mastodon.social/@Shaos


Last edited by Shaos on 01 Jun 2013 00:23, edited 5 times in total.



29 Nov 2005 09:19
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22409
Location: Silicon Valley
Reply with quote
Post 
Пока предполагается следующее - превратить Zpring в безромный эмулятор Спринтера, Спектрума и Турбо-2+ (может еще и Ориона в придачу). "Безромный" - значит никаких ромов! Вся эмуляция только через самые популярные точки входа плюс поддержка соответствующих форматов экрана и стандартов переключения страниц памяти. 100% совместимости нет и не будет по понятным причинам - точки входа буду подрубать только по мере необходимости для того или иного софта, который надо будет заставить работать в эмуле (собственно я так и делал в SPRINT-e).

_________________
:dj: https://mastodon.social/@Shaos


06 Jan 2006 23:31
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22409
Location: Silicon Valley
Reply with quote
Post 
Shaos wrote:
Пока предполагается следующее - превратить Zpring в безромный эмулятор Спринтера, Спектрума и Турбо-2+ (может еще и Ориона в придачу). "Безромный" - значит никаких ромов! Вся эмуляция только через самые популярные точки входа плюс поддержка соответствующих форматов экрана и стандартов переключения страниц памяти. 100% совместимости нет и не будет по понятным причинам - точки входа буду подрубать только по мере необходимости для того или иного софта, который надо будет заставить работать в эмуле (собственно я так и делал в SPRINT-e).


Появилось кому что сказать на поставленную тему?

_________________
:dj: https://mastodon.social/@Shaos


24 Sep 2006 18:17
Profile WWW
Retired

Joined: 03 Aug 2003 22:37
Posts: 1474
Location: Moscow
Reply with quote
Post 
Могу лишь повторить то, что говорил раньше - надо улучшить эмуляцию системы прерываний второго рода процессора Z80 :)

_________________
Extreme Entertainment


24 Sep 2006 19:57
Profile
God
User avatar

Joined: 29 Dec 2003 01:00
Posts: 1101
Location: Москва
Reply with quote
Post 
Mac Buster wrote:
Могу лишь повторить то, что говорил раньше - надо улучшить эмуляцию системы прерываний второго рода процессора Z80 :)

АГа, в качестве теста бери смело мой "Клад", он вовсю их использует.


25 Sep 2006 00:28
Profile ICQ WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22409
Location: Silicon Valley
Reply with quote
Post 
Через 10 лет после публичного релиза последней версии эмулятора SPRINT выходит его реинкарнация под давно обещанным именем Zpring:

Image

Потихоньку экспериментирую со спектрумовыми режимами через альтернативный ром BasicSE :roll:

_________________
:dj: https://mastodon.social/@Shaos


29 May 2013 21:19
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22409
Location: Silicon Valley
Reply with quote
Post 
Под MacOS X на PowerPC пока есть проблемы со сборкой и проблемы с "big endian" - сборка корректируется вот таким более универсальным Makefile:
Code:
CC = g++
CFLAGS = `sdl-config --cflags` -I. -Wall -O2 -DSDL
# -DBASICSE
LFLAGS = `sdl-config --libs` -lm -lpthread
OBJS = targa.o unigraf.o bios.o z80/z80.o z80/z80_ops.o

all: zpring

clean:
        rm -f *.o
        rm -f z80/*.o

z80/z80.o: z80/z80.cpp z80/z80.h
        $(CC) $(CFLAGS) -c z80/z80.cpp -o z80/z80.o

z80/z80_ops.o: z80/z80_ops.cpp z80/z80.h z80/z_cb.hpp z80/z_ddfd.hpp z80/z_ddfdcb.hpp z80/z_ed.hpp z80/z_macros.h
        $(CC) $(CFLAGS) -c z80/z80_ops.cpp -o z80/z80_ops.o

bios.o: bios.cpp bios.h zpring.h
        $(CC) $(CFLAGS) -c bios.cpp

unigraf.o: unigraf.cpp unigraf.h
        $(CC) $(CFLAGS) -c unigraf.cpp -DFONT8X8 -DUNIFOPEN

targa.o: targa.cpp targa.h
        $(CC) $(CFLAGS) -c targa.cpp

zpring: zpring.cpp bios.h zpring.h z80/z80.h $(OBJS)
        $(CC) zpring.cpp $(CFLAGS) -o zpring $(LFLAGS) $(OBJS)

Проблему "big endian" пока не поправил...

P.S. Кроме того мой код использует сканкоды кнопок клавиатуры, передавая их в эмулируемые программы как есть, а на аппловском железе сканкоды совсем другие - придётся переделывать код обработки клавиатуры, делая маппинг из высокоуровневых SDL-макросов в эмулируемые PC-сканкоды...

_________________
:dj: https://mastodon.social/@Shaos


31 May 2013 03:01
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22409
Location: Silicon Valley
Reply with quote
Post 
Добавил голосовалку - голосуем :roll:

_________________
:dj: https://mastodon.social/@Shaos


01 Jun 2013 00:22
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22409
Location: Silicon Valley
Reply with quote
Post Re:
Вот наткнулся на версию моего эмулятора Спринтера, приспособленную под 64-битную Mac OS X:

https://github.com/suborb/sprint

Надо поглядеть чего они там наменяли...

_________________
:dj: https://mastodon.social/@Shaos


20 May 2018 14:45
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22409
Location: Silicon Valley
Reply with quote
Поправил исходники, чтобы собирались и работали в 64-битном линухе (проверял на своём серваке AMD64).

Проверил, что всё что должно работать из примеров всё также работает, а также поправил урлы на стартовой страничке:


Attachments:
Zpring.gif
Zpring.gif [ 38.94 KiB | Viewed 16289 times ]

_________________
:dj: https://mastodon.social/@Shaos
28 Nov 2020 06:30
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22409
Location: Silicon Valley
Reply with quote
Проверил, что и в DOS оно всё также собирается и работает :mrgreen:

Attachment:
ZpringDOS.png
ZpringDOS.png [ 34.68 KiB | Viewed 16289 times ]


Широкий экран в оконном режиме из под Linux тоже работает нормально:

Attachment:
ZpringWide.png
ZpringWide.png [ 33.11 KiB | Viewed 16219 times ]

_________________
:dj: https://mastodon.social/@Shaos


28 Nov 2020 07:11
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22409
Location: Silicon Valley
Reply with quote
Надо будет слегка перелопатить исходники т.к. на самом деле в SPRINT у меня всегда предполагалось, что рисуем и показываем мы одну и туже видеостраницу т.е. нельзя было показывать одну и рисовать в другую, а потом типа эту другую вывести на экран...

_________________
:dj: https://mastodon.social/@Shaos


29 Nov 2020 04:41
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22409
Location: Silicon Valley
Reply with quote
Shaos wrote:
Надо будет слегка перелопатить исходники т.к. на самом деле в SPRINT у меня всегда предполагалось, что рисуем и показываем мы одну и туже видеостраницу т.е. нельзя было показывать одну и рисовать в другую, а потом типа эту другую вывести на экран...
Вобщем 2 экрана планирую добавить так (и даже больше чем это) - вывод графики (а также опрос кнопок клавы и мыши) у меня идёт через C++ класс UniGraf (который внутри имеет реализации для SDL, svgalib и DOS переключаемые условной компиляцией), который поддерживает абстрактные пикселы, которые могут быть больше реальных пикселов экрана и даже могут быть совсем неквадратные - поэтому у меня получается выводить спринтеровский экран 640x256 в графическое окно 800x600 и вообще окно (или экран) любого размера (причём размер может быть даже меньше эмулируемого). Копирование в окно (на экран) идёт через периодически вызываемый метод Update, в котором например в случае SDL просто стоит вызов SDL_UpdateRect(PRIV->screen,0,0,dx,dy); копирующий копию экрана из системной памяти в видеопамять. Так вот мне надо добавить новый закадровый экран как отдельный объект SDL_Surface размером БОЛЬШЕ видимой области и блиттить его часть по вызову метода Update - левую часть закадрового буфера (страница 0), либо правую часть закадрового буфера (страница 1). Можно даже дальше пойти и сымитировать полную видеопамять 512КБ (хоть она и не поддержана в реальной железяке), добавив ещё одну такую же пару экранов ниже первой пары (т.е. закадровый буфер получит размер в 1024 полупикселей (512 байт) на 512 строк (причём с увеличением пропорционально целевому окну). Более того - пользуясь тем фактом, что у нас уже будет буфер больше видимого экрана, можно относительно просто реализовать горизонтальный и вертикальный СКРОЛЛИНГ причём с заворачиванием в кольцо (точнее в тор)! Для эмуляции Спринтера скроллинг само собой ненужен, но для будущего компьютера Zpring он очень даже не помешает :)

Одно НО (точнее два) - это будет работать только в SDL, т.к. в реализации через svgalib для Linux и через ваткомовский graph.h для DOS никаких сурфейсов в UniGraf нету и весь вывод идёт прямо на экран путём вывода пикселей в нужные места согласно коэффициенту увеличения для каждого абстрактного пиксела. Скажем реализацию для svgalib я выкину - с некоторых пор этой графической библиотекой для консольного линуха на ПЦ стало не так то просто пользоваться (она лет 10 назад стала требовать подгрузки специального модуля ядра из под рута) и я даже не в курсе будет ли она работать с современными дистрами линукса (из дебияна её похоже выкинули ещё в 2013) - как говориться фиг с ней, а вот DOS мне хотелось бы сохранить - возможно в ваткомовском graph.h есть поддержка закадровых буферов и мне надо просто ей правильно воспользоваться - буду смотреть...

P.S. Почитал про ваткомовскую графику - там можно только сохранять экран в image и восстанавливать его потом обратно, т.е. придётся научиться рисовать в такую сохранённую картинку и при переключении экранов просто копировать правильную картинку в экран - выходит полноценного плавного скроллинга не получится т.к. картинка копируется только целиком, хоть и в произвольные координаты. Можно попробовать программно скроллировать, но это будет наверное несколько тормозно. Вот как WATCOM рассчитывает размер буфера под картинку:
Code:
long _WCI86FAR _CGRAPH _imagesize( short x1, short y1, short x2, short y2 )   
/*==================================================================== 
 
   This routine returns the size of buffer needed to store the picture 
   in the rectangle defined by ( x1, y1 ) and ( x2, y2 ), in viewport 
   coordinates. */   
   
{   
    if( _GraphMode() ) {   
        return( _L2imagesize( _VtoPhysX( x1 ), _VtoPhysY( y1 ),   
                              _VtoPhysX( x2 ), _VtoPhysY( y2 ) ) );   
    } else {   
        return( 0 );   
    }   
}   
   
Entry( _IMAGESIZE, _imagesize ) // alternate entry-point   
   
   
long _WCI86FAR _L2imagesize( short x1, short y1, short x2, short y2 )   
/*============================================================== 
 
   This routine returns the size of buffer needed to store the picture 
   in the rectangle defined by ( x1, y1 ) and ( x2, y2 ), in physical 
   coordinates. */   
{   
#if defined( _DEFAULT_WINDOWS )   
// For Windows and OS/2, the size is only the size of the record   
    x1 = x1;   
    x2 = x2;   
    y1 = y1;   
    y2 = y2;   
    return( sizeof( struct picture ) );   
#else   
    short               xwid;   
    short               ywid;   
    long                size;           /* size of image */   
   
    xwid = abs( x2 - x1 ) + 1;   
    ywid = abs( y2 - y1 ) + 1;   
    size = (long)ywid * _RowLen( xwid );   
    return( size + 6L );   
#endif   
}   
   
   
short _RowLen( short pixels )   
/*=========================== 
 
    This routine calculates the number of bytes needed to store one row 
    of pixels. */   
   
{   
    short               size;   
   
    if( _CurrState->misc_info & PLANAR ) {   
        size = ( ( pixels + 7 ) / 8 ) * _CurrState->vc.bitsperpixel;   
    } else {   
        size = ( ( pixels * _CurrState->vc.bitsperpixel + 7 ) / 8 );   
    }   
    return( size );   
}   

что при палитровом режиме 8 бит на пиксел должно просто стать dx*dy+6 (если я всё правильно понял) и при имитации скрола надо просто копировать эти 6 лишних байтов в правильное место.

P.P.S. В этих 6 байтах запоминаются значения picwidth, picheight и bpp (это если я нагуглил правильные сырцы)...

_________________
:dj: https://mastodon.social/@Shaos


04 Dec 2020 03:50
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22409
Location: Silicon Valley
Reply with quote
Прикрутил сохранение в PNG вместо TGA:

Attachment:
Zp0003.png
Zp0003.png [ 12.34 KiB | Viewed 13632 times ]


Attachment:
Zp0002.png
Zp0002.png [ 10.44 KiB | Viewed 13632 times ]


Attachment:
Zp0001.png
Zp0001.png [ 4.75 KiB | Viewed 13631 times ]

_________________
:dj: https://mastodon.social/@Shaos


17 Nov 2021 01:12
Profile WWW
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22409
Location: Silicon Valley
Reply with quote
По итогам стрима про портирование эмуля на макос оно таки заработало:

Attachment:
zpring-macos-small.jpg
zpring-macos-small.jpg [ 210.71 KiB | Viewed 12798 times ]


Версия собираемая в MacOS уже выложена на гитлаб (для успешной сборки нужен brew через который ставится sdl и в котором уже есть libpng)

_________________
:dj: https://mastodon.social/@Shaos


23 Nov 2021 00:03
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 29 posts ]  Go to page 1, 2  Next

Who is online

Users browsing this forum: No registered users and 14 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.