Citanje color offset-a za svaki pixel u indexed color .bmp file-u?

[Chupo]

Ukratko:

Da li u Java-i postoji mehanizam za citanje color offset-a za svaki
pojedinacni pixel u indexed color .bmp file-u?

Opsirnije:

Napravio sam generiranje tile i sprite ROM file-ova za Pac-Man hardware
koji kao ulaz uzima 4 bpp (16 color) .bmp file. Pac-Man hardware ima
tile-ove i sprite-ove definirane s 2 bita po pixelu ali s obzirom da ne
postoji 2 bpp .bmp koristim 4 bpp .bmp file u kojem sam definirao samo
prva 4 unosa za paletu.

Problem je jer za citanje boje pixela koristim getRGB() metodu pa sam
boje morao hardkodirati. Kada bih umjesto RGB komponenti za pojedini
pixel mogao procitati offset u color paleti, onda boje ne bi morale
biti hardkodirane pa bi program radio s .bmp file-ovima koji su
nacrtani korisnjem bilo koje 4 boje.

Da li u Java-i postoje neke motode s kojima bi mogo doci do offset-a na
color paletu koji opisuje svaki pixel ili je jedini nacin da citam .bmp
file header i raspakiram pixel array?

Trenutno sam u .bmp file-u na offset-u 0x36 (color paleta) stavio:

00000036h: 00 00 00 00 FF FF FF 00 00 00 FF 00 FF 00 00 00

To su 4 boje, svaka boja je opisana s 4 byte-a u formatu BGRA pa je to:

0x00 crna
0x01 bijela
0x02 plava
0x03 crvena

Ako za crtanje koristim te 4 boje onda mogu na osnovu RGB vrijednosti
pixela odrediti offset u toj paleti, ali ako bi htio koristiti neke
druge 4 boje onda bih morao mijenjati program pa mi zato umjesto
citanja RGB vrijednosti pixela treba citanje offset-a u color paleti.

Program koji radi s hardkodiranim vrijednostima izgleda ovako:

package pacman;

import java.awt.image.BufferedImage;
import java.io.File;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.RandomAccessFile;

import javax.imageio.ImageIO;

// Reads tile.bmp, generates raw output.bin and overwrites the
// first 16 bytes in pacman.5e ROM file with the same 16 bytes

public class Tilegen {

// returns byte describing 4 pixel column at position i
// i = 0 --> down-right, i = 15 --> up-left
public static int get4px(int i, int data[][]) {
int x;
int y;
int out = 0;

x = 7 - (i % 8); // x coord in array
y = 7 - (i / 8)*4; // y coord in array

// bits 0 & 4 (bit 0 and bit 1 shifted to position 4)
out |= (data[x][y] & 0x01) | ((data[x][y] & 0x02) << 3);
// bits 1 & 5 (bit 0 shifted to position 1 and bit 1 shifted to
position 5)
out |= ((data[x][y-1] & 0x01) << 1) | ((data[x][y-1] & 0x02)
<< 4);
// bits 2 & 6 (bit 0 shifted to position 2 and bit 1 shifted to
position 6)
out |= ((data[x][y-2] & 0x01) << 2) | ((data[x][y-2] & 0x02)
<< 5);
// bits 3 & 7 (bit 0 shifted to position 3 and bit 1 shifted to
position 7)
out |= ((data[x][y-3] & 0x01) << 3) | ((data[x][y-3] & 0x02)
<< 6);

return out;
}

public static void main(String[] args) throws IOException {
final File file = new File("tile.bmp"); // 8x8 .bmp
file (4 of 16 colors used)
final BufferedImage image = ImageIO.read(file);
final FileOutputStream outfile = new FileOutputStream
("output.bin"); // output hex file
final File romfile = new File("pacman.5e"); // ROM file
final RandomAccessFile tilerom = new RandomAccessFile(romfile,
"rw");
tilerom.seek(0L);

int data[][] = new int[8][8]; // to store pixel data
int out;

for (int y=0; y < image.getHeight(); y++) {
for (int x=0; x < image.getWidth(); x++) {
final int color = image.getRGB(x, y);
final int red = ((color & 0x00ff0000) >> 16); //
removing ( ) breaks auto indentation in Eclipse!?
final int green = ((color & 0x0000ff00) >> 8); //
removing ( ) breaks auto indentation in Eclipse!?
final int blue = color & 0x000000ff;

if ((red == 0xff) && (green == 0xff) && (blue == 0xff))
{
//System.out.print("1 "); // white is 1
out = 1;
} else if (red == 0xff) {
//System.out.print("3 "); // red is 3
out = 3;
} else if (blue == 0xff) {
//System.out.print("2 "); // blue is 2
out = 2;
} else {
//System.out.print("0 "); // black is 0
out = 0;
}
System.out.print(out + " ");
data[x][y] = out & 0xff;
}
System.out.println();
}

System.out.println();
// map data to ROM file format
for (int i=0; i < 16; i++) {
out = get4px(i, data);
System.out.println(out + " ");
outfile.write(out);
tilerom.write(out); // change byte in the ROM file
}

tilerom.close();
outfile.close();
} // main
} // class

Jos opsirnije:

https://stackoverflow.com/q/44991780/1324175

[Bruno Babic]

Post by Chupo
Da li u Java-i postoji mehanizam za citanje color offset-a za svaki
pojedinacni pixel u indexed color .bmp file-u?

AFAIK, Java ce ucitati BMP kao sliku... sve ostalo moras citati kao
binary file, a onda ti je svejedno.

Jesi li isprobao neki drugi file format? PCX na primjer?
https://en.wikipedia.org/wiki/PCX

[Chupo]

Post by Bruno Babic
AFAIK, Java ce ucitati BMP kao sliku... sve ostalo moras citati kao
binary file, a onda ti je svejedno.

Onda mi je prakticki isto ko da program pisem u C-u. Pisao sam ga u
Java-i samo zato jer sam vidio da se do informacija o pixelima moze
doci bez citanja binary file-a.

Post by Bruno Babic
Jesi li isprobao neki drugi file format? PCX na primjer?
https://en.wikipedia.org/wiki/PCX

Mislis zbog toga jer podrzava i 2 bpp slike? U clanku uopce nije
objasnjena struktura 128 byte-nog header-a :-/

ps
Nesta me zeza news reader, iako sam poruku poslao i na
comp.programiranje vidim ju samo na programiranje.java.

Na comp.programiranje ne vidim niti poruku koju sam poslao niti reply.

Prije par dana mi je newsreader (Microplanet Gravity) za jedno 15 news
grupa javio sljedecu poruku:

<start copy/paste>
Your newsserver has reset all the article numbers for newsgroup
hr.ime.grupe. Server reports lowest article 0 instead of xxxx
Gravity expects the article numbers to increase. This is the mechanism
by which Grabity detects new article headers.

Until this problem is corrected, Gravity can not download headers for
this newsgroup.

To work around this problem, you can unsubsscribe from this newsgroup
and later resubscribe to it. Note that this will erase all information
in the newsgroup.
<end copy/paste>

Na svim tim grupama za koje mi je izbacilo tovu poruku vise ne mogu
primati nove header-e. Unsubscribe pa ponovni subscribe taj problem
rjesava ali bi si u tom slucaju izbrisao na desetke i desetke poruka
koje imam oznacene kao 'protected' a koje su stare i po 10 godina pa
trazim neko drugo rjesenje.

[Bruno Babic]

Post by Chupo
Mislis zbog toga jer podrzava i 2 bpp slike? U clanku uopce nije
objasnjena struktura 128 byte-nog header-a :-/

Ima i drugih linkova koje objasnjavaju strukturu PCX-a:
http://www.fastgraph.com/help/pcx_header_format.html

Post by Chupo
ps
Nesta me zeza news reader, iako sam poruku poslao i na
comp.programiranje vidim ju samo na programiranje.java.

Izgleda da su T-comovci digli novi news server, a nisu bili u stanju
napraviti 1-to-1 kopiju pa je puno grupa resetirano. I ja sam imao isti
problem, ali ne cuvam stare poruke pa sam samo napravio refresh svega.

Post by Chupo
Na svim tim grupama za koje mi je izbacilo tovu poruku vise ne mogu
primati nove header-e. Unsubscribe pa ponovni subscribe taj problem
rjesava ali bi si u tom slucaju izbrisao na desetke i desetke poruka
koje imam oznacene kao 'protected' a koje su stare i po 10 godina pa
trazim neko drugo rjesenje.

Ne postoji bolje rjesenje jer, kao sto ti i reader kaze, ID novih poruka
je manji od ID-ja starih poruka i tu ne mozes napraviti nista jer je
problem nastao na serveru.

Provjeri da li mozes napraviti nesto kao backup stanja kakvo sad imas,
pa ga po potrebi browsati... ili, ako nista drugo onda barem na neki
nacin rucno promijeniti ID svih poruka koje si spremio.

[Chupo]

Post by Bruno Babic
http://www.fastgraph.com/help/pcx_header_format.html

Post by Chupo
ps
Nesta me zeza news reader, iako sam poruku poslao i na
comp.programiranje vidim ju samo na programiranje.java.

Ali za to opet moram raditi s binary file-om pa mi onda dodje na isto
ko i da .bmp otvaram ko binary file a s .bmp sam vec radio tako da znam
struturu skoro na pamet.

Post by Bruno Babic
Izgleda da su T-comovci digli novi news server, a nisu bili u stanju
napraviti 1-to-1 kopiju pa je puno grupa resetirano. I ja sam imao isti
problem, ali ne cuvam stare poruke pa sam samo napravio refresh svega.

To znaci da niti Thunderbird 'ne zna' normalno nastaviti raditi kad se
na serveru resetira article count?! Netko tko radi newsreader bi morao
ugraditi rjesenje za slucaj kad se to desi.

Post by Bruno Babic

Post by Chupo
Na svim tim grupama za koje mi je izbacilo tovu poruku vise ne mogu
primati nove header-e. Unsubscribe pa ponovni subscribe taj problem
rjesava ali bi si u tom slucaju izbrisao na desetke i desetke poruka
koje imam oznacene kao 'protected' a koje su stare i po 10 godina pa
trazim neko drugo rjesenje.

Ne postoji bolje rjesenje jer, kao sto ti i reader kaze, ID novih poruka
je manji od ID-ja starih poruka i tu ne mozes napraviti nista jer je
problem nastao na serveru.

U ovom thread-u sam napisao dva moguca rjesenja:

http://tinyurl.com/yddc7r5z

Problem je jer ja koristim MicroPlanet Gravity build 2060, verziju
poznatiju pod imenom Super Gravity:

http://gravity.tbates.org/super.html

a za nju mislim da ne postoji izvorni kod. To je verzija koju je
napravio jedan od sluzbenih autora nakon sta je projekt napusten a
nakon toga je krenuo Gravity Open Source project za kojega postoji
izvorni kod ali se je struktura baza promijenila a i iz programa je
izbaceno dosta opcija koje su u originalu postojale (a Super Gravity ih
ima jos vise od originala).

Post by Bruno Babic
Provjeri da li mozes napraviti nesto kao backup stanja kakvo sad imas,
pa ga po potrebi browsati... ili, ako nista drugo onda barem na neki
nacin rucno promijeniti ID svih poruka koje si spremio.

To sam vec napravio, Gravity ima zasebni program za backup svega tako
da se u par sekundi na novoj instalaciji moze sve vratiti na stanje
backup-irano na nekom drugom kompjuteru. Slozio sam i rule s kojim sam
sadrzaj svih protected article-a exportirao u .txt file tako da
sadrzaje nece biti izgubljem (file ima 201729 linija s normalnim
header-ima a 290870 linija kad je ukljuceno Show Full Headers).

Kako sam napisao u tom thread-u na kojeg sam dao link, neki postovi su
mi arhivirani jos od 2005. godine.

Na toj bi se grupi vjerojano mogo pojaviti i neko od autora originalnog
Gravity-a a poslao sam i mail ovom covjeku:

http://gravity.tbates.org/

Taj mi je par puta odgovorio na neka pitanje u vezi Gravity-a ali je to
bilo jos 2005. godine :-)

Zanimljivo je procitati i kako je program nastao:

http://mpgravity.sourceforge.net/#history

Sad BTW ponovo ove postove vidim i na comp.programiranje a ne samo na
comp.programiranje.java - jer sam na comp.programiranje napravio
unsubscribe pa opet subscribe - i izgubio protected postove :-(

[Bruno Babic]

Post by Chupo
Ali za to opet moram raditi s binary file-om pa mi onda dodje na isto
ko i da .bmp otvaram ko binary file a s .bmp sam vec radio tako da znam
struturu skoro na pamet.

Javina klasa BufferedImage ima metodu getRGB() kojom mozes dohvatiti sve
pixele, ali mi se to cini kao overkill za ono sto tebi treba.

[Bruno Babic]

Post by Bruno Babic
Javina klasa BufferedImage ima metodu getRGB() kojom mozes dohvatiti sve
pixele, ali mi se to cini kao overkill za ono sto tebi treba.

Pogledaj i ovo, tu ekipa pise o tome kako dohvate pixele kao byte array
pa rade puno brze (ali to ti je kao i parsanje binarnog filea):

https://stackoverflow.com/questions/6524196/java-get-pixel-array-from-image

[Chupo]

Post by Bruno Babic
Javina klasa BufferedImage ima metodu getRGB() kojom mozes dohvatiti sve
pixele, ali mi se to cini kao overkill za ono sto tebi treba.

Pa u inicijalnom postu sam napisao:

<start copy/paste>
Problem je jer za citanje boje pixela koristim getRGB() metodu pa sam
boje morao hardkodirati.
<end copy/paste>

Stavio sam i cijeli program koji pocinje s:

import java.awt.image.BufferedImage;

Ali s getRGB() dobijem komponente boje pixela a meni trebaju offset-i
na paletu tako da mogu crtati koristenjem bilo koje palete a na izlazu
dobiti iste podatke.

Meni u izlaznim podacima treba s koja od 4 index-a na boje je neki
pixel pofarban a ako mogu procitati samo RGB komponente onda bi u
programu morao znati koja boja je na kojem index-u - tako program radi
trenutno i sad bi svaki put dok bi za crtanje koristio drugu paletu
morao u programu mijenjati uvjete u if - else if bloku.

Znaci mene zanima da li je neki pixel pofarbano s nultom, prvom, drugom
ili trecom bojom iz palete od 16 boja a bez potrebe da u programu
definiram koje se boje nalaze na tovim mjestima.

Cini se da je najjednostavnije da najprije file otvorim kao binarni pa
da na offset-u 0x36 procitam RGB komponente od prve 4 boje u paleti i
da onda dalje radim na isti nacin ko i do sad s tim da RGB komponente u
if - else if bloku vise nece biti hardkodirane nego ce biti prethodno
iscitane iz palete.

S obzirom da getRGB() u svakom slucaju, da bi mogla doci do komponenti,
mora najprije procitati offset na boju u paleti - trebali su staviti i
metodu getColorOffset() koja bi za svaki pojedini pixel vracala offset
na paletu - a to je ustvari broj (u ovom slucaju nibble) procitan iz
pixel array-a koji na osnovu kojeg se je iscitao integer iz palete.

Taj offset se interno za realiziranje getRGB() ionako vec koristi ali
je problem da nisu stavili get metodu da bi ga se moglo procitati.

[Bruno Babic]

Post by Chupo
Meni u izlaznim podacima treba s koja od 4 index-a na boje je neki
pixel pofarban a ako mogu procitati samo RGB komponente onda bi u
programu morao znati koja boja je na kojem index-u - tako program radi
trenutno i sad bi svaki put dok bi za crtanje koristio drugu paletu
morao u programu mijenjati uvjete u if - else if bloku.

Zato sam i preporucio PCX - imas u startu odgovarajuci format, a vecina
editora podrzava taj format.

Post by Chupo
Znaci mene zanima da li je neki pixel pofarbano s nultom, prvom, drugom
ili trecom bojom iz palete od 16 boja a bez potrebe da u programu
definiram koje se boje nalaze na tovim mjestima.

Usporedi RGB pixela sa RGB vrijednoscu za neku od te 4 boje i to je to?
RGB pixela prebacis u int, i onda dalje usporedjujes integere.

[Chupo]

Post by Bruno Babic
Zato sam i preporucio PCX - imas u startu odgovarajuci format, a vecina
editora podrzava taj format.

Mislis zato jer .pcx ima i 2 bpp boju? Ali sta to vrijedi kad opet
moram raspakiravati pixel array. Onda mi je ipak jednostavnije
procitati paletu u .bmp-u pa koristiti getRGB().

Post by Bruno Babic
Usporedi RGB pixela sa RGB vrijednoscu za neku od te 4 boje i to je to?
RGB pixela prebacis u int, i onda dalje usporedjujes integere.

Da, to cu napraviti. Ali mi je nekako bilo logicno da ako postoji Java
library za rad s .bmp file-om - da bi se s njim moglo doci do nekih
elementarnih informacija o .bmp file-u.

BTW, napravio sam sve sta mi treba da bi mogo napraviti igru na Pac-Man
hardware-u. Pa ipak me jos uvijek vise zanima Scramble hardware za
kojeg nemam informacija. Zbog toga sam probao ici obrnutim putem,
probao sam u MAME source-u traziti informacije o Pac-Man hardware-u
koje znam - pa da onda analogijom na osnovu Scramble-ovih source-va
dodjem do informacija koje mi trebaju za Scramble HW.

Za sad sam proucio:

galaxian.h
pacman.h
scramble.h

drivers/galaxian.cpp
drivers/pacman.cpp
drivers/scramble.cpp

video/galaxian.cpp
video/pacman.cpp
video/scramble.cpp

i jos par file-ova ali je sve skupa previse apstrahirano i jos nisam
locirao rutinu koja mapira podatke iz tile i sprite ROM file-ova u
pixele koji se prikazuju u emulatoru. Kad lociram tove rutine za
emuliranje Pac-Man hardware-a onda cu analogijom locirati iste rutine
za Scramble hardware pa cu iz njih zakljuciti kakva je struktura
podataka u originalnim ROM-ovima. S obzirom da strukturu podataka za
Pac-Man hardware znam - ne bi mi trebalo biti tesko prepoznati kod koji
se odnosi na mapiranje tih podataka, jer on mora biti slican mojem kodu
za generiranje podataka u ROM-u koji radi obrnuto.

[Bruno Babic]

Post by Chupo
BTW, napravio sam sve sta mi treba da bi mogo napraviti igru na Pac-Man
hardware-u. Pa ipak me jos uvijek vise zanima Scramble hardware za
kojeg nemam informacija. Zbog toga sam probao ici obrnutim putem,
probao sam u MAME source-u traziti informacije o Pac-Man hardware-u
koje znam - pa da onda analogijom na osnovu Scramble-ovih source-va
dodjem do informacija koje mi trebaju za Scramble HW.

Ne postoji "scramble hardware". To je sve u MAME-u neki od baznih
emulatora koji je mozda nesto malo izmijenjen sa necime sto je mozda
specificno za igru Scramble.
Dakle, sve sto trebas je saznati koji je to CPU u pitanju i nekakav
osnovni memory layout.

Koliko ja vidim iz scramble.cpp, video RAM je od 0x4800 do 0x4bff,
spriteovi su od 0x5040 do 0x505f, itd.

Post by Chupo
i jos par file-ova ali je sve skupa previse apstrahirano i jos nisam
locirao rutinu koja mapira podatke iz tile i sprite ROM file-ova u
pixele koji se prikazuju u emulatoru. Kad lociram tove rutine za
emuliranje Pac-Man hardware-a onda cu analogijom locirati iste rutine
za Scramble hardware pa cu iz njih zakljuciti kakva je struktura
podataka u originalnim ROM-ovima. S obzirom da strukturu podataka za

Sumnjam da to radi tako kako si ti zamislio. ROM file se direktno ucita
u sadrzaj memorije, nema nikakvog raspakriavanja i interpretiranja u
MAME-u. Ako te zanima kako izgledaju spriteovi, gledaj sadrzaj ROM filea
od 0x5040 pa nadalje i to je to. Samo obrati paznju da je moguce da je
ROM rascjepkan u vise fileova koji se odmah ucitavaju na odgovarajucu
lokaciju (da se ustedi na velicini arhive).

[Chupo]

Post by Bruno Babic
Ne postoji "scramble hardware".

Kako ne, Scramble hardware je baziran na Galaxians hardware-u.

Post by Bruno Babic
To je sve u MAME-u neki od baznih
emulatora koji je mozda nesto malo izmijenjen sa necime sto je mozda
specificno za igru Scramble.
Dakle, sve sto trebas je saznati koji je to CPU u pitanju i nekakav
osnovni memory layout.

MAME je slozen tako da emulira svaki fizicki segment elektronike, od
processora, EEPROMA, PROM-ova, TTL cipova do diskretnih elektronickih
sklopova realiziranih s komponentama (tranzistorima, TTL gate-ovima,
linijama za kasnjenje itd.). S obzirom da su proizvodjaci iste cipove
koristili u vise aparata ne mora postojati zaseban driver za neki
aparat a u novijim verzijama MAME-a koje su u C++ je sve organizirano u
clase Machine, Device i slicno a sve se konfigurira s macro-ima.

U medjuvremenu sam skinuo source od prve verzije MAME-a iz 1997. u
kojoj je radio samo Pac-Man i jos 4 igre:

http://wiki.mamedev.org/index.php/Previous_MAME_Versions

Prvih par godina je sve bilo pisano u cistom C-u i tu je puno lakse
pratiti kako emulatori funkcioniraju. MAME je inace zapocet kao
emulator Pac-Man-a i nastao je od MultiPac emulatora:

http://caesar.logiqx.com/php/emulator.php?id=multipac

U Pac-Man-u recimo sliku iscrtava NVC293 video shifter kojega je Namco
napravio za Pac-Man-a i Rally X ali on u svakom aparatu radi drukcije.

Ako skines MAME 0.1 (ciji source ima samo 500 KB za razliku od 730 MB
koliko ima source od najnovije verzije) u file-u common.c ces u
funkciji:

struct GfxElement *decodegfx(const unsigned char *src,const struct
GfxLayout *gl)

vidjeti funkciju koja sadrzaj tile i sprite ROM-ova mapira u array za
iscrtavanje na ekranu kompjutera (koristio se je Allegro library).

Post by Bruno Babic
Koliko ja vidim iz scramble.cpp, video RAM je od 0x4800 do 0x4bff,
spriteovi su od 0x5040 do 0x505f, itd.

To nije dovoljno jer treba zakljuciti kako su podaci organizirani a
bili su prilagodnjeni hardware-u za iscrtavanje slike. U Pac-Man
hardware-u se za boju pixela koriste bit plane-ovi tako da pripadajuci
bitovi koji kontroliraju boju nisu jedan do drugoga. Po dva bita
odredjuju koja od 4 boje iz tablice boja ce se koristiti za pojedini
pixel, tablica boja (colortable) je niz paleta od po 4 boje a svaki
unos u paletu je index na boje u obliku:

B B G G G R R R

Svaka od tih struktora podataka (paleta, colortable, tile/sprite) je u
drugom EPROM-u tako da EPROM za paletu ima samo 32 byte-a. U prvim
verzijama MAME-a su ti podaci bili hardkodirani a u kasnijim verzijama
se i podaci iz manjih PROM-ova citaju iz ROM file-ova pa je tako paleta
za Pac-Man hardware u file-u:

82s123.7f

U ovom dokumentu mozes vidjeti kako su organizirani podaci u tile i
sprite ROM-u za Pac-Man hardware:

https://www.lomont.org/Software/Games/PacMan/PacmanEmulation.pdf

ali ti podaci nazalost nisu tocni. Tocno mapiranje podataka iz sprite
ROM-a koje je u tom dokumentu pogresno mozes iscitati iz moje rutine za
generiranje sprite ROM-a:

package pacman;

import java.awt.image.BufferedImage;
import java.io.File;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.RandomAccessFile;

import javax.imageio.ImageIO;

public class Spritegen {

// vraca byte koji opisuje stupac od 4 pixela na poziciji i (0 -
63)
public static int get4px(int i, int data[][]) {
int x;
int y;
int out = 0;

x = 15 - ((i % 8) + (i / 32)*8); // x koordinata u
array-u
y = (15 + (i / 8)*4) % 16; // y
koordinata u array-u
System.out.println(x + ", " + y);

// bit 0 i 4 (bit 0 i bit 1 pomaknut na mjesto 4)
out |= (data[x][y] & 0x01) | ((data[x][y] & 0x02) << 3);
// bit 1 i 5 (bit 0 pomaknut na mjesto 1 i bit 1 pomaknut
na mjesto 5)
out |= ((data[x][y-1] & 0x01) << 1) | ((data[x][y-1] &
0x02) << 4);
// bit 2 i 6 (bit 0 pomaknut na mjesto 2 i bit 1 pomaknut
na mjesto 6)
out |= ((data[x][y-2] & 0x01) << 2) | ((data[x][y-2] &
0x02) << 5);
// bit 3 i 7 (bit 0 pomaknut na mjesto 3 i bit 1 pomaknut
na mjesto 7)
out |= ((data[x][y-3] & 0x01) << 3) | ((data[x][y-3] &
0x02) << 6);

return out;
}

public static void main(String[] args) throws IOException {

final File file = new File("sprite.bmp");
// slika
final BufferedImage image = ImageIO.read(file);
final FileOutputStream outfile = new FileOutputStream
("output.bin"); // izlazni file
final File romfile = new File("pacman.5f");
// ROM file
final RandomAccessFile tilerom = new RandomAccessFile
(romfile, "rw"); // citanje i pisanje
tilerom.seek(0L);

int data[][] = new int[16][16]; // za direktno
upisivanje podataka iz slike
int out;

for (int y=0; y < image.getHeight(); y++) {
for (int x=0; x < image.getWidth(); x++) {
final int boja = image.getRGB(x, y);
final int red = ((boja & 0x00ff0000) >> 16);
final int green = ((boja & 0x0000ff00) >> 8);
final int blue = boja & 0x000000ff;

if ((red == 0xff) && (green == 0xff) && (blue
== 0xff)) {
//System.out.print("1 "); //
bijela je 1
out = 1;
} else if (red == 0xff) {
//System.out.print("3 "); //
crvena je 3
out = 3;
} else if (blue == 0xff) {
//System.out.print("2 "); //
plava je 2
out = 2;
} else {
//System.out.print("0 "); //
crna je 0
out = 0;
}
System.out.print(out + " ");
data[x][y] = out & 0xff;
}
System.out.println();
}

System.out.println();
// ovdje treba procitane vrijednosti mapirati u ispravnom
rasporedu za tile ROM
for (int i=0; i < 64; i++) {
out = get4px(i, data);
//System.out.println(out + " ");
outfile.write(out); // upisi byte u
izlazni file
tilerom.write(out); // promijeni byte
u ROM file-u
}

tilerom.close();
outfile.close();

} // main

} // class

Do toga kako su podaci u sprite ROM-u mapirani sam doso editiranjem
ROM-ova pa iscrtavanjem sprite-ove i zakljucivanjem kako su razbacani
bitovi a iz ovih nekoliko clanaka se moze vidjeti da su isti nacin
koristili i autori MAME drivera:

http://aarongiles.com/old-stuff/mame-memories/

Trebalo je zapaziti da svaki byte kontrolira 4 pixela s tim da su
parovi bitova za svaki pixel svaki u svojem nibble-u, recimo prvi pixel
kontroliraju nulti i cetvrti bit, drugi pixel prvi i peti bit, treci
pixel kontroliraju drugi i sesti bit a cetvrti pixel treci i sedmi bit.

Sprite ima 16x16 pixela a svaki byte kontrolira 4 pixela pa sam gledao
kako se mijenjaju x i y koordinate od baznog pixela u grupama od po 4
pixela koje kontrolira jedan byte iz sprite ROM-a. Takvih grupa ima 64
pa ako se brojac krece od 0 do 63 onda se x koordinata mijenja ovako:

x = 15 - ((i % 8) + (i / 32)*8);

Slicno tome, ako se y izracuna kao:

y = (15 + (i / 8)*4) % 16;

onda se dobije sljedeci niz koordinata:

15, 15
14, 15
13, 15
12, 15
11, 15
10, 15
9, 15
8, 15
15, 3
14, 3
13, 3
12, 3
11, 3
10, 3
9, 3
8, 3
15, 7
14, 7
13, 7
12, 7
11, 7
10, 7
9, 7
8, 7
15, 11
14, 11
13, 11
12, 11
11, 11
10, 11
9, 11
8, 11
7, 15
6, 15
5, 15
4, 15
3, 15
2, 15
1, 15
0, 15
7, 3
6, 3
5, 3
4, 3
3, 3
2, 3
1, 3
0, 3
7, 7
6, 7
5, 7
4, 7
3, 7
2, 7
1, 7
0, 7
7, 11
6, 11
5, 11
4, 11
3, 11
2, 11
1, 11
0, 11

a to su upravo koordinate najdoljnjeg pixela u svakoj grupi od po 4
pixela koju kontrolira jedan byte podataka. To su koortidnate dna
svakog od 64 stupca koji sadrzi 4 pixela u onom redosljedu u kojem su
podaci iz ROM-a mapirani unutar sprite-a.

Ako se nacrta mreza u kojoj se oznaci koje pixele koji byte kontrolira
onda se relativno lako moze uociti taj uzorak. Logicno je da se
mapiranje mora moci zapisati s par logickih operacija jer su podaci
prilagodjeni hardware-u za iscrtavanje slike.

Umjesto (i % 8) se moze pisati (i & 7) a umjesto (i / 16) se moze
pisati (i >> 4) a to su upravo operacije koje je radio hardware za
prikaz videa.

Medjutim, niti samo ti podaci nisu dovoljni nego ima jos cijeli niz
podataka koje treba znati da bi se moglo poceti pisati program za
hardware od nekog od tih starijih aparata. Jer svaki je imao jos
nekoliko vanjskih slopova s kojima se je komuniciralo preko memorijski
mapiranih portova ili OUT instrukcija (na Pac-Man-u se koristi i jedno
i drugo). Dodatno sve skupa otezava cinjenica da na nekim portovima
citanje ima jednu funkciju a pisanje drugu. Recimo kad se port cita se
dobiju podaci s joystick-a i slotova od zetonjere, a kad se u taj isti
port pise onda se kontrolira vanjski hardware za generiranje
interrupta. Da bi stvari bile jos kompliciranij, neka pisanja se izvode
tako da se ne koristi data bus nego se pise preko adresnih linija preko
bitova koji su u hardware-u za dekodiranje adrese maskirani.

[Bruno Babic]

Napisao si puno toga sto je meni sve jasno i na cemu sam odrasao... ipak
sam svojedobno rasturao na C64, rezultat cega je cak i jedna "konkretna"
igra (http://iscro.com/stuff/retro/c64/atomix.t64)

Ono sto sam ja htio reci je da se ne moras baviti toliko necime sto je
specificno za scramble hardware ukoliko znas da je u pitanju npr. taj i
taj procesor te da je npr. layout spriteova takav i takav, da se nalaze
tu i tu u memoriji, gdje su koje bitnije memorijske lokacije, itd. To je
bila poanta onoga sto sam napisao.

Da sam ja na tvom mjestu, ja bih uzeo osnovni scramble i napravio od
njega jednostavan peek/poke program i taj program bih vrtio pod MAME-om.
Zasto? Zato sto bi ti takav program lako omogucio da vizualiziras sve
sto taj hardware moze. Poke-as na memorijsku lokaciju da ukljucis
sprite, pa na lokaciju za poziciju na ekranu i vec si dobio nekakvo
vizualizirano "smece". Zatim pokeas konkretan sadrzaj i voila... znas
kako raditi sa spriteovima bez da reverese engineeras Scramble, sto je
osjetno sporije.
Uz Commodore 64 je uredno dolazila knjiga sa listom bitnih memorijskih
lokacija, sve je tamo pisalo... tako nesto tebi treba za taj scramble
hardware, odnosno galaxian, odnosno Z80 (koliko vidim, to je CPU).

Jos bolje rjesenje je da napises svoj jednostavni device za MAME,
baziran na scramble deviceu, koji ce doslovno ucitati svih 64k ROM-a
(ili koliko vec ima taj hardware) i ti onda lako iz nekog viseg jezika
kreiras taj ROM dump kojeg ucitavas u MAME da vidis rezultat svog rada.

[Chupo]

Post by Bruno Babic
Napisao si puno toga sto je meni sve jasno i na cemu sam odrasao... ipak
sam svojedobno rasturao na C64, rezultat cega je cak i jedna "konkretna"
igra (http://iscro.com/stuff/retro/c64/atomix.t64)

Covjece, ovo je vrhunski!! :-) Svaka cast!! Imao sam na jednom od hard
diskova Frodo i program radi odlicno. Vidim da si koristio stvari za
koje je potrebna single cycle emulacija jer u frodo.exe i frodopc.exe
intro ne radi ispravno. Linije se na granici border-a i ekrana ne
spajaju nego se vide stepenice a kad se pokrene s frodo.exe onda fali
donji dio naptpisa 'Atomix' i donji polovica texta 'Issie SW 1994' se
stalno pomice desno pa skace na pocetno mjesto. Ali u frodosc.exe sve
radi bez greske.

Jedva sam se sjetio:

LOAD"$",9
LIST
LOAD"ATOMIX",9,1

Osmica je mapirana na folder s primjerima koji dolaze s emulatorom pa
sam koristio devetku.

Znaci dobar si u 6502 :-) Ja sam s 12 godina poceo uciti Z80 assembler
i za vrijeme visih razreda osnovne sam uz pisanje grafickih rutina i
rutina za zvuk za Spectruma pratio sve sta je o Z80 bilo u Racunarima,
Svetu kompjutera i manje u Moj Mikro i plus toga proanalizirao
kompletan Spectrumov ROM ukljucujuci i rutine za aproximaciju
trigonometrijskih funkcija koje onda jos nisam mogo shvatiti (Taylorovi
redovi, Cebisevljvi polinomi), odnosno shvacao sam kako te rutine rade
ali onda jos nisam znao kako je moguce da se na takav nacin dobije
relativno tocna vrijednost sinusa i jos nekih funkcija pomocu kojih se
onda racunaju sve ostale.

Vjerojatno znas da Spectrum nema hardware-ske sprite-ove i da svo
iscrtavanje za svaki frame moras raditi software-ski a organizacija
Spectrumove memorije je poznata po svemu samo ne po jednostavnoj
layout-u (mada ima i puno kompliciranijih mapiranja).

Na pisanju rutina koje sprite-ove iscrtavale tako da su prvo spremale
pozadinu pa onda radile AND izmedju maske i pozadine, pa OR izmedju
rezultata i definicije 'sprite' (i u sljedecem frame-u vracale
spremljenu pozadinu) se je moglo stvarno puno nauciti. Nije toliki
problem napisati rutine koje to rade, ali je veliki problem napisati
rutine koje to rade dovoljno brzo da ostane vremena i za ostale stvari,
pogotovo jer Spectrum nema ni hardware za zvuk pa i sve valne oblike
treba generirati upisivanjem jednog bita (istina, postoje rutine koje
osim bita za kontrolu zvucnika mijenjaju i bit za MIC OUT pa to onda
zbog hardware-ske izvedbe utjece na high level i na frekvencijsku
karakteristiku odziva - jer pull-up otpornici, kondenzatori i zvucnik
predstavljaju kombinaciju RC i RL filtara).

Dosta sam naucio i na skidanju zastita (po Atomix intro-u bi reko da i
ti isto :-)) ) i na disassembliranju rutina za generiranje zvuka u
komercijalnim igrama.

Dok mi je stric posudio Commodore-a sam naucio i 6502 ali taj mi se
assembleri nikada nije dopadao. Smetala mi je memorijski orijentirana
arhitektura sa samo 3 registra, adresiranjem preko nulte stranice i to
da za istu stvar vecinom treba napisati vise linija nego na Z80 pa onda
nisam niti detaljnije proucavao Commodore. SID mi je bio zanimljiv ali
mi se je nakon rutina za Spectrum (gdje se prakticki mora kontrolirati
kretanje membrane zvucnika) cinilo da je prejednostavno zvuk dobiti
upisivanjem brojeva u memorijski mapiranje registre :-)

Uvijek sam se pitao gdje su sad svi oni ljudi koji su osamdesetih i
devedesetih radili intro-e, trebali bi se jednom naci na picu i malo
popricati o tim vremenima :-)

Post by Bruno Babic
Ono sto sam ja htio reci je da se ne moras baviti toliko necime sto je
specificno za scramble hardware ukoliko znas da je u pitanju npr. taj i
taj procesor

Scramble ima dva Z80, jedan na manjoj frekvenciji je za zvuk. Za zvuk
ima i jos dva AY cipa.

Post by Bruno Babic
te da je npr. layout spriteova takav i takav

E vidis, to kakav je layout sprite-ova i tile-ova na Scramble-u (jos
uvijek) ne znam :-)) Problem je da su se dizajneri hardware-a trudili
cim vise zakomplicirati stvari da bi bootleg-erima otezali upgrade
starih aparata na nove igre bez narucivanja conversion kit-ova.

Iz ovog se clanka vidi koliko ima posla s otkrivanjem kako radi
odredjeni hardware:

http://aarongiles.com/old-stuff/mame-memories/hunting-for-color-proms/

I to pise covjek koji je pisao firmware za particle generator u CERN-u.

Istina je da su sad svi ti podaci u MAME-u ali nije bas jednostavno do
njih doci analiziranjem koda a ono sta se nalazi u komentarima (ako ih
ima) je daleko od dovoljnog.

Post by Bruno Babic
da se nalaze
tu i tu u memoriji, gdje su koje bitnije memorijske lokacije, itd. To je
bila poanta onoga sto sam napisao.
Da sam ja na tvom mjestu, ja bih uzeo osnovni scramble i napravio od
njega jednostavan peek/poke program i taj program bih vrtio pod MAME-om.
Zasto? Zato sto bi ti takav program lako omogucio da vizualiziras sve
sto taj hardware moze. Poke-as na memorijsku lokaciju da ukljucis
sprite, pa na lokaciju za poziciju na ekranu i vec si dobio nekakvo
vizualizirano "smece". Zatim pokeas konkretan sadrzaj i voila... znas
kako raditi sa spriteovima bez da reverese engineeras Scramble, sto je
osjetno sporije.

Upravo sam tako i doso do layout-a za tile-ove i sprite-ove na Pac-Man
hardware-u. MAME ima odlicne alate za vizualizaciju tile-ova, paleta i
sprite-ova i dovoljno je promijeniti podatke u ROM-ovima pa u tim
alatima pogledati kako nakon izmjena izgledaju recimo sprite-ovi.

Ali taj postupak, cak i uz hrpu informacija koju sam o Pac-man
hardware-u imao iz raznih dokumenata s neta, nije bio bas trivijalan.

Ono isto sta sam napravio za Pac-Man hardware bi trebao napraviti za
Scramble-ov hardware - razlika je jedino u tome da sam za ovaj prvi
naso puno informacija koje su mi olaksale/ubrzale postupak. Koristio
sam informacije za cije su prikupljanje nekim ljudima trebale godine.

Post by Bruno Babic
Uz Commodore 64 je uredno dolazila knjiga sa listom bitnih memorijskih
lokacija, sve je tamo pisalo... tako nesto tebi treba za taj scramble
hardware, odnosno galaxian, odnosno Z80 (koliko vidim, to je CPU).

Upravo to i trazim - problem je medjutim u tome da ne samo da takva
dokumentacija nije nikad objavljena, nego su se i autori tih uredjaja
jako potrudili da cim vise zakompliciraju analiziranje.

Post by Bruno Babic
Jos bolje rjesenje je da napises svoj jednostavni device za MAME,
baziran na scramble deviceu, koji ce doslovno ucitati svih 64k ROM-a
(ili koliko vec ima taj hardware) i ti onda lako iz nekog viseg jezika
kreiras taj ROM dump kojeg ucitavas u MAME da vidis rezultat svog rada.

Cim ja kreiram ROM-ove pa u .zip-u neke od originalnih zamijenim s
mojima, istog trenutka nakon pokretanja tovog aparata u MAME-u mogu
stisnuti F4 i vidjeti kako bi izgledao sprite/tile definiran s mojim
podacima. Nije problem niti napisati kratki program u assembleru koji
ce obrisati ekran pa prikazati sprite a onda se vrtjeti u beskonacnoj
petlji u kojoj ce resetirati watchdog timer. Ali to je samo jedan mali
dio price. Na takav nacin bi se dosta tesko moglo otkriti da su dio
video memorije i adrese koje uzrokuju da se pripadajuci tile-ovi
'prikazuju' izvan ekrana. Pac-Man recimo ima u svakom uglu ekrana 4
tile-a koja se nikad ne vide a ta se mjesta mogu recimo iskoristiti da
se na njih pomakne sprite kojega treba 'ugasiti'. Koliko vidim i na
Scramble hardware-u se watchdog resetira *citanjem* iz odredjene
memorijske lokacije, na Pac-Man-u se on resetira pisanjem. Tu opet nije
jasno sta tocno znaci broj upisan u tovu lokaciju jer counter ima
sigurno vise od 8 bitova a u originalnom programu za Pac-Man-a se moze
vidjeti da u nekim slucajevima u lokaciju za brisanje watchdog-a
program svaki put upisuje sve manji i manji broj. Koliko vidim jos
nitko nije otkrito zasto. Ja sam u programu recimo stavio da se u tu
lokaciju uvijek upisuje nula i cini se da sve radi OK. Takvih stvari
koje je dosta tesko otkriti ima na desetke.

BTW, vidim da u Atomix-u na pocetku intro-a i nakon pokretanja programa
na vrhu ekrana titraju karakteri - da li to znaci da si variable za
rutinu koja raspakirava podatke (ili prije pokretanja prebacuje program
na drugu lokaciju) stavio u video RAM?

[Bruno Babic]

Post by Chupo
Covjece, ovo je vrhunski!! :-) Svaka cast!! Imao sam na jednom od hard
diskova Frodo i program radi odlicno. Vidim da si koristio stvari za
koje je potrebna single cycle emulacija jer u frodo.exe i frodopc.exe

Istina, svaki cycle se mora emulirati jer razliciti efekti ustvari
cekaju da VIC dodje sa iscrtavanjem do neke linije ekrana kako bi
zapoceli svoj posao... ako se preskoci jedan cycle, teoretski se kod na
tom dijelu nece pozvati sve do slijedeceg iscrtavanja (kada se mozda
opet ne pozove) itd.

Post by Chupo
Znaci dobar si u 6502 :-) Ja sam s 12 godina poceo uciti Z80 assembler

Tamo negdje '95 sam sanjao u 6502 assembleru i znao sve C64 memorijske
lokacije napamet, a sada bih najvjerojatnije morao sve ispocetka uciti :)

Post by Chupo
Dosta sam naucio i na skidanju zastita (po Atomix intro-u bi reko da i
ti isto :-)) ) i na disassembliranju rutina za generiranje zvuka u
komercijalnim igrama.

Recimo to ovako - vise-manje sve sam naucio reverse-engineeringom
introa... a bome ekipa je se znala posteno potruditi da ti otezaju da
dodjes do njihovog koda.

Post by Chupo
Uvijek sam se pitao gdje su sad svi oni ljudi koji su osamdesetih i
devedesetih radili intro-e, trebali bi se jednom naci na picu i malo
popricati o tim vremenima :-)

Nebi me bilo tesko nagovoriti da se nadjemo i uzivo... ako se ne varam,
mi smo obojica u okolici VZ?

Post by Chupo

Post by Bruno Babic
Uz Commodore 64 je uredno dolazila knjiga sa listom bitnih memorijskih
lokacija, sve je tamo pisalo... tako nesto tebi treba za taj scramble
hardware, odnosno galaxian, odnosno Z80 (koliko vidim, to je CPU).

Upravo to i trazim - problem je medjutim u tome da ne samo da takva
dokumentacija nije nikad objavljena, nego su se i autori tih uredjaja
jako potrudili da cim vise zakompliciraju analiziranje.

Uh, ako je to zbilja tako onda doslovno moras sve raditi metodom
pokusaja i pogresaka, a to mi se cini kao iznimno dugotrajan proces.

Jesi li barem u stanju napisati jednostavan program koji npr. pomjera
sprite kako korisnik pomjera joystick? (pod uvjetom da znas otkud
procitati stanje joysticka)

Post by Chupo
BTW, vidim da u Atomix-u na pocetku intro-a i nakon pokretanja programa
na vrhu ekrana titraju karakteri - da li to znaci da si variable za
rutinu koja raspakirava podatke (ili prije pokretanja prebacuje program
na drugu lokaciju) stavio u video RAM?

Upravo tako, to je jedna od najosnovnijih zastita - dekriptiras svoj kod
kroz video RAM pa na taj nacin otezas posao onome tko zeli doci do
dekriptiranog koda jer ne smije napraviti nista sto mijenja sadrzaj
ekrana. No, onaj tko zna da lako promijenis lokaciju video RAM-a lako to
i zaobidje. Zato sam ubacio i jos jednu foru, a to je da se kod koji
dekriptira nalazi na memorijskim lokacijama koje su inace "ispod" ROM-a,
pa moras iskljuciti ROM da bi uopce mogao vidjeti moj kod.

[Chupo]

Post by Bruno Babic
Istina, svaki cycle se mora emulirati jer razliciti efekti ustvari
cekaju da VIC dodje sa iscrtavanjem do neke linije ekrana kako bi
zapoceli svoj posao... ako se preskoci jedan cycle, teoretski se kod na
tom dijelu nece pozvati sve do slijedeceg iscrtavanja (kada se mozda
opet ne pozove) itd.

Na Spectrumu se takvi efekti mogu postici jedino tako da u interrupt
rutini potrosis odredjeni broj T-stanja dok elektronski snop ne stigne
na trazeno mjesto. Intrrupt se generira s VBLANK kad pocinje vertrical
retrace i onda naprije treba pocekati da snop stigne natrag gore pa do
vidljivog dijela ekrana i onda treba cekati u petlji koja uvijek traje
tocno toliko taktova koliko traje iscrtavanje jedne linije. Posljedica
je da cim se efekt nalazi nize ostaje manje vremena za stvari van
interrupt rutine. Tako se moze crtati po borderu ili se moze postici
vise od dvije boje po 8x8 pixela. Pretpostavljam da se na Pac-Man
hardware-u na slican nacin moze iscrtati vise sprite-ova nego sta ih
ima u hardware-u i da se tako moze postici vise od 4 boje po karakteru,
napisao sam rutinu koja bi na pravom harware-u trebala raditi ali na
MAME-u se to ne moze provjeriti jer se u njemu ekran update-a istog
trenutka cim se nesta upise u odgovarajuci registar - bez obzira na to
gdje se trenutno nalazi elektroniski snop. U mojim komentarima na ovaj
video sam napisao opis rutine:

Post by Bruno Babic
Tamo negdje '95 sam sanjao u 6502 assembleru i znao sve C64 memorijske
lokacije napamet, a sada bih najvjerojatnije morao sve ispocetka uciti :)

Brzo bi se sjetio svega. Ja sam prije par godina iz zezancije napisao
par interrupt rutina za Spectruma:

i odma sam se sjetio svega.

Da sam nekad imao crosscompiler i emulator... SjASMPlus kojega sam
koristio je najbolji Z80 compiler kojeg sam vidio a uz to jos moze i
generirati Spectrum-om snapshot (.sna) file kojega se onda samo otvori
u emulatoru. U vrijeme dok sam stalno pisao programe za Spectrum sam
program od par desetaka byte-ova mogo napisati direktno u .hex-u bez da
sam ucitavao assembler. Eventualno sam tu i tamo pogledao opcode od
neke instrukcije.

Jos i sad znam napamet adrese dosta sistemskih variabli ili vaznijih
rutina u ROM-u a na Spectrumu nema memorijski mapiranih portova ili
periferija nego se koriste IN i OUT instrukcije. Jedino sta je mapirano
u memoriju je video RAM.

Post by Bruno Babic
Recimo to ovako - vise-manje sve sam naucio reverse-engineeringom
introa... a bome ekipa je se znala posteno potruditi da ti otezaju da
dodjes do njihovog koda.

Ja sam najvise naucio na skidanju zastita koje su stavili ljudi koji su
probili komercijalne zastite. Njihove su nerijetko bile kompilicranije
od komercijalnih jer su kombinirali stvari koje su naucili dok su
probijali pojedinacne komercijalne zastite. I puno sam naucio iz
analiziranja SAVE i LOAD rutina iz ROM-a i speed loader-a koje su
koristile neke igre. Tu mora isto sve biti tocno do na takt a na Z80 to
nije bas jednostavno postici jer trajanja instrukicija su od 4 do 23 T.

Post by Bruno Babic
Nebi me bilo tesko nagovoriti da se nadjemo i uzivo... ako se ne varam,
mi smo obojica u okolici VZ?

Moramo se jednom dogovoriti da se nadjemo. Ja sam u ZG ali sam jako
cesto u okolici Toplica. Dok sam tu onda se s biciklom krecem u krugu
od Kalnika do Ivanscice, Beletinca, Beretinca, Vidovca i okolice a s
autom sam cesto u Varazdinu.

Post by Bruno Babic
Uh, ako je to zbilja tako onda doslovno moras sve raditi metodom
pokusaja i pogresaka, a to mi se cini kao iznimno dugotrajan proces.
Jesi li barem u stanju napisati jednostavan program koji npr. pomjera
sprite kako korisnik pomjera joystick? (pod uvjetom da znas otkud
procitati stanje joysticka)

Za Pac-Man hardware mogu napisati sve i prije nego pocnem isprobavati s
pisanjem koda za Scramble HW cu napraviti neku igru na Pac-Man-u. Mogo
bi bas napraviti port Atomix-a!! :-)) S obzirom da Pac-Man HW nema ni
jednu dodatnu tipku (Scramble ima Fire i Bomb) cu morati iskoristiti
tipku za 1 Player Start. Mogu napraviti sve gdje ne trebaju kosi
smjerovi, vise od dvije tipke (mogo bi iskoristiti i tipku za 2 Player
Start) i gdje ne treba scroll background-a za po 1 pixel. Probao sam
ocitavati kose smerove, napisao sam rutinu koja ispisuje hex vrijednost
memorijske lokacije s koje se ocitava joystick ali nikad nije resetiran
vise od jedan bit tako da se mogu ocitatati samo 4 smjera. Mislim da
originalni Pac-Man-ov joystick niti nema hod u koso. Ovo sam si inace
slozio za testiranje:

https://www.dropbox.com/sh/wzju38868exoybm/AAAWVaPnSqPqM07BIEYvfEsDa

Bas cu dok uhvatim malo vremena probati na Pac-Man hardware-u napraviti
prvi ekran od Atomix-a. Za takve igre (u tu kategoriju spada i Sokoban)
me je uvijek zanimalo kako izmisliti dovoljan broj sve tezih i tezih
nivoa a koji se sigurno mogu rijesiti.

Post by Bruno Babic
Upravo tako, to je jedna od najosnovnijih zastita - dekriptiras svoj kod
kroz video RAM pa na taj nacin otezas posao onome tko zeli doci do
dekriptiranog koda jer ne smije napraviti nista sto mijenja sadrzaj
ekrana. No, onaj tko zna da lako promijenis lokaciju video RAM-a lako to
i zaobidje. Zato sam ubacio i jos jednu foru, a to je da se kod koji
dekriptira nalazi na memorijskim lokacijama koje su inace "ispod" ROM-a,
pa moras iskljuciti ROM da bi uopce mogao vidjeti moj kod.

Bilo je nevjerojatnih trikova za otezavanje pronalazenja koda. Recimo
program se je s kazete poceo ucitavati u neku visoku memorijsku
lokaciju i nakon sta je counter za memorijsku lokaciju u koju se byte
ucitava doso do kraja RAM-a (65535) se je dalje 'ucitavalo' u
memorijske lokacije od 0 pa dalje preko ROM-a i onda u video memoriju
pa preko systemskih variabli gdje se je prebrisao vektor za skok u
slucaju greske kod ucitavanja (ERRSP) a onda se je program nastavio
ucitavati dalje preko nizih adresa RAM-a i snimka je namjerno imala
jedan byte manje nego je bilo procitano iz header-a. To je uzrokovalo
gresku kod ucitavanja zbog koje se je onda program pokrenuo od adrese
na koju je pokazivao ERRSP a tamo je bila rutina za visestruko
prebacivanje koda na drugu lokaciju i istovremeno XOR-iranje svakog
byte-a s drugom vrijednoscu. Neki programi su cak radili XOR s
vrijednoscu R registra koji se na Z80 nakon svake instrukcije povecava
za jedan (osim sedmog bita koji se nikad ne mijenja) s tim da se za
instrukcije koje imaju jedan od 4 prefixa R povecava za dva pa bi se
moglo zakljuciti da se prefix racuna ko jos jedan instrukcija ali za
instrukcije s 2 prefixa u opcode-u se R opet povecava za 2. Znalo je
biti po 4 ili 5 premjestanja i XOR-iranja blokova byte-ova pa skoka na
adresu u bloku i onda jos i premjestanje i XOR-iranje s R koji se
stalno mijenja.

Ova zastita je osim otezavanja dolaska do koda uzrokovala i da program
koji se ucitava bude duzi od ukupnog RAM-a (jer se je ucitavao i preko
ROM-a pa su ti byte-ovi bili visak) tako da ga se nije moglo ucitati u
neki od programa za kopiranje.

Da sam onda imao emulator i debugger ko sad bi stvari za koje su mi
onda trebali dani napravio u par sati. Onda sam morao u RAM ucitavati
dio po dio koda jer mi je dio RAM-a zauzimao disassembler pa sam, ako
se je blok prije pokretanja kopirao na adrese koje je trenutno zauzimao
disassembler, morao pripremiti rutinu koja ce otpakirati 'jedan korak'
pa opet ispocetka i tako po 5-6 puta a kod je bio namjerno pisan tako
da bi se moglo pomisliti da si ga pogresno otpakirao i da je to
bezvezan niz byte-ova.

[Bruno Babic]

Post by Chupo
Moramo se jednom dogovoriti da se nadjemo. Ja sam u ZG ali sam jako
cesto u okolici Toplica. Dok sam tu onda se s biciklom krecem u krugu
od Kalnika do Ivanscice, Beletinca, Beretinca, Vidovca i okolice a s
autom sam cesto u Varazdinu.

Aha, to me je zbunilo jer mi je Katalenic Zlatko spomenuo da te zna, pa
sam pomislio da si tu negdje u blizini, a vas dvojica se valjda znate s
biciklistickih dogadjanja.

Post by Chupo
originalni Pac-Man-ov joystick niti nema hod u koso. Ovo sam si inace

Vidim ja da cemo se mi morati definitivno naci uzivo jer meni u kutiji
vec godinama stoje gumbi, joysticki i kontroler koji sve to spaja na
prolazni PS2 prikljucak. Naime, mislio sam si u DIY maniru napraviti
MAME box, ali nisam uspio nabaviti arkadni kabinet, pa je ta ideja
nekako dobila niski prioritet i onda na kraju zena, djeca i zivot sve to
potisnuli u podrum. Sada su me ove tvoje slike podsjetile na sve to i
ideja mozda opet zazivi.

Post by Chupo
Bas cu dok uhvatim malo vremena probati na Pac-Man hardware-u napraviti
prvi ekran od Atomix-a. Za takve igre (u tu kategoriju spada i Sokoban)
me je uvijek zanimalo kako izmisliti dovoljan broj sve tezih i tezih
nivoa a koji se sigurno mogu rijesiti.

Samo reci ukoliko trebas neku pomoc, rado cu uskociti, pa makar morao
uciti Z80 assembler :)
Inace, levele sam sam dizajnirao, pomalo uz pomoc uzdbenika iz kemije,
pomalo onako bezveze izmisljao jer mi je sa svakim levelom trebala
kompleksnija molekula. Sto se sigurnog rjesavanja tice, to se svelo na
to da ja pokusavam rijesiti sve dok ne uspijem pa ako je prelako onda
malo zakompliciram i tako sve dok nisam bio zadovoljan rezultatom.

Post by Chupo
Da sam onda imao emulator i debugger ko sad bi stvari za koje su mi
onda trebali dani napravio u par sati. Onda sam morao u RAM ucitavati

Ja sam tamo negdje pocetkom 2000-tih sasvim slucajno nabavio modul za
C64 koji je imao u sebi ugradjen softver za "hakiranje". Stisnes tipku i
dodjes u nekakvo sucelje koje ti omogucava da gledas i mijenjas sadrzaj
memorije i pises kod. Do tada sam sve to radio sa zicom kojom sam spajao
pinove na portu da se C64 resetira bez da pobrise RAM i onda ucitavao
program (koji je omogucavao vizualizaciju i promjenu memorije) na neku
lokaciju gdje sam ga mogao pokrenuti bez da pregazi kod koji me zanimao.
Isto kao sto i ti pises, komad po komad dekriptiravao da bih na kraju
dosao do dekriptiranog koda kojeg sam snimio da bih ga mogao reverse
engineerati.

P.S. ovo polako prelazi tematiku grupe pa mozda da nastavimo na mail?

[Chupo]

Post by Bruno Babic
Aha, to me je zbunilo jer mi je Katalenic Zlatko spomenuo da te zna, pa
sam pomislio da si tu negdje u blizini, a vas dvojica se valjda znate s
biciklistickih dogadjanja.

S njim se znam oduvijek jer je nekad zivio u bakinom selu. A on na
posao svaki dan ide s biciklom iz Vrtlinovca u Sigetec pa cesto znam
nakon sta mu zavrsi radno vrijeme otici do Ludbrega pa dalje s njim do
njegove kuce i to mi je 47 km za zagrijavanje :-)

Post by Bruno Babic
Vidim ja da cemo se mi morati definitivno naci uzivo jer meni u kutiji
vec godinama stoje gumbi, joysticki i kontroler koji sve to spaja na
prolazni PS2 prikljucak. Naime, mislio sam si u DIY maniru napraviti
MAME box, ali nisam uspio nabaviti arkadni kabinet, pa je ta ideja
nekako dobila niski prioritet i onda na kraju zena, djeca i zivot sve to
potisnuli u podrum. Sada su me ove tvoje slike podsjetile na sve to i
ideja mozda opet zazivi.

Za izradu ovog testnog 'kucista' je frendu bez ikakvih nacrta trebalo
doslovno 10 minuta :-)

Post by Bruno Babic
Samo reci ukoliko trebas neku pomoc, rado cu uskociti, pa makar morao
uciti Z80 assembler :)

S obzirom da znas 6502 bi lako u roku par sati naucio assembler za
Microchip-ove (PIC) mikrokontrolere jer je jako slican 6502. U njemu
sam pisao dosta programa ali sad vec dugo koristim Atmel-ove
mikrokontrolere koji imaju assembler slican Z80 ali u assembleru pisem
samo kriticne dijelove koda a ostalo sve u C-u.

Post by Bruno Babic
Inace, levele sam sam dizajnirao, pomalo uz pomoc uzdbenika iz kemije,
pomalo onako bezveze izmisljao jer mi je sa svakim levelom trebala
kompleksnija molekula. Sto se sigurnog rjesavanja tice, to se svelo na
to da ja pokusavam rijesiti sve dok ne uspijem pa ako je prelako onda
malo zakompliciram i tako sve dok nisam bio zadovoljan rezultatom.

Bas cu za vjezbu napraviti Atomix za Pac-Man hardware. Jedino moram
provjeriti da li vec ne postoji ista igra za MAME. Na YT vidim da osim
verzije za PC i C64 postoji i online flash verzija:

http://mylostgames.com/play/atomix

Post by Bruno Babic
Ja sam tamo negdje pocetkom 2000-tih sasvim slucajno nabavio modul za
C64 koji je imao u sebi ugradjen softver za "hakiranje". Stisnes tipku i
dodjes u nekakvo sucelje koje ti omogucava da gledas i mijenjas sadrzaj
memorije i pises kod. Do tada sam sve to radio sa zicom kojom sam spajao
pinove na portu da se C64 resetira bez da pobrise RAM i onda ucitavao
program (koji je omogucavao vizualizaciju i promjenu memorije) na neku
lokaciju gdje sam ga mogao pokrenuti bez da pregazi kod koji me zanimao.
Isto kao sto i ti pises, komad po komad dekriptiravao da bih na kraju
dosao do dekriptiranog koda kojeg sam snimio da bih ga mogao reverse
engineerati.

Na Spectrumu je isto bilo dodataka s kojima se je moglo zaustaviti
program pa ga analizirati ali to nisam imao. Frend je imao Disciple
floppy kontroler na kojem je bila i tipka s kojom se je u bilo kojem
trenutku mogo u par sekudni napraviti snapshot trenutnog stanja:

https://en.wikipedia.org/wiki/DISCiPLE

Post by Bruno Babic
P.S. ovo polako prelazi tematiku grupe pa mozda da nastavimo na mail?

Moze :-)

[Nikolaj Lazic]

["Followup-To:" header set to hr.comp.programiranje.]
Dana Wed, 19 Jul 2017 16:21:35 +0200, Chupo <***@yahoo.com> napis'o:
[snip]

Post by Chupo

Post by Bruno Babic
P.S. ovo polako prelazi tematiku grupe pa mozda da nastavimo na mail?

Moze :-)

A, mozda ipak ne?

Mozda ipak nekog malo potakne na nakucati nesto.
Kao mene sad prisjecanje na C64 i speeddos ROM koji je paralelno imao
standardni ROM i modificirani za pralalelni prijenos sa floppy drive-a.
A, imao je i direktan hexa prikaz memorije koji je dobro dosao za
pregledavanje.
Kak to da nije spomenut tasm na c64? To je tak fini assembler za c64.
A, nulta strana na 6502 je tak super fora sa hrpom pointera koje mozes
vrtiti po zelji. Fino zamisljeno.
Meni dobro doslo za full screen scroll rutinu.
Mozda cak i imam negdje na disketama... ali nemam vise niti c64 niti
drive. Otislo prije hrpu godina. :(

[Nikolaj Lazic]

Dana Wed, 19 Jul 2017 17:08:21 +0000 (UTC), Nikolaj Lazic <***@mudrac.ffzg.hr> napis'o:
[snip]

Post by Nikolaj Lazic
Kak to da nije spomenut tasm na c64? To je tak fini assembler za c64.

Pricam o ovom...
turbo.style64.org

Uopce se ne sjecam u cemu sam pisao programe prije tog programa.

[Chupo]

Post by Nikolaj Lazic
A, mozda ipak ne?
Mozda ipak nekog malo potakne na nakucati nesto.

Siguran sam da (i kod nas) ima ljudi koje zanima razvoj software-a koji
bi radio na orginalnim arkadnim aparatima i kompjuterima iz osamdesetih
pa cu, s obzirom da vec dugo vremena planiram pokrenuti neki blog,
vjerojatno staviti neka uputstva jer nekima koji su nekad programirali
u assembleru mozda fali samo par informacija o tome kako se sad s
emulatorima i crosscompilerima moze razvijati takav software - i to
daleko brze nego nekad. Recimo ja sad imam sve sta mi treba da napravim
bilo kakav program koji ce raditi na Pac-Man hardware-u a danas sam na
osnovu source-a od MAME 0.1 uspio shvatiti kako je u emulatoru opisano
mapiranje podataka u tile i sprite ROM-ovima i sad cu konacno moci
dekodirati layout-e i za Scramble.

Post by Nikolaj Lazic
Kao mene sad prisjecanje na C64 i speeddos ROM koji je paralelno imao
standardni ROM i modificirani za pralalelni prijenos sa floppy drive-a.
A, imao je i direktan hexa prikaz memorije koji je dobro dosao za
pregledavanje.

Evo vidis, ti i Bruno znate 6502 pa bi mogli uzeti neki od aparata koji
je bio baziran na nekom od processora iz te familije:

http://docs.mamedev.org/techspecs/m6502.html

Ovdje se npr. moze vidjeti koji aparati su koristili 6502:

http://users.axess.com/twilight/sock/dk/other.html

Ja sam si sad slozio kompletan toolchain za Pac-Man hardware, pomocu
SjASMPlus crosscompiler-a mogu s compile direktno kreirati ROM file-ove
koji sadrze kod a u Java-i sam slozio generiranje tile-ova i sprite-ova
tako da se podaci upisuju direktno u postojeci ROM file i zamjenjuju
originalne podatke. Tako sad nakon sta nesta dopisem u program mogu
samo stisnuti compile pa onda generirani ROM file s drag'n'drop ubaciti
u .zip file u kojem su svi ROM file-ovi za Pac-Man-a pa iste sekunde
taj .zip file pokrenuti s MAME i vidjeti rezultat.

Post by Nikolaj Lazic
Kak to da nije spomenut tasm na c64? To je tak fini assembler za c64.
A, nulta strana na 6502 je tak super fora sa hrpom pointera koje mozes
vrtiti po zelji. Fino zamisljeno.

Vjerojatno je takav nacin logican nekome kome je primarni assembler bio
6502 ali netko tko je vecinom pisao programe za Z80 ima potpuno drugu
logiku. Jer Z80 ima hrpu registara a instrukcije koje rade s memorijom
su spore i opcode-ovi takvih instrukcija zauzimaju vise byte-ova pa je
cilj pristupanje memoriji smanjiti na najmanju mogucu mjeru.

Ovdje BTW mozes vidjeti kako sam radio reverse engineering uredjaja za
citanje IR kodova, assembler za Microchip-ove mikrokontrolere je po
nacinu pisanja programa dosta slican 6502 assembleru:

http://chupo.50webs.com/rev_eng/

To je ustvari samo djelic koda kojega sam disassemblirao a text sam
napisao za clanak na nekom forumu gdje su ljudi mislili da ce nakon
iscitavanja .hex-a iz EEPROM-a moci jednostavno izmijeniti program pa
dodati nove funkcije - kao da imaju izvorni kod :-)

Post by Nikolaj Lazic
Meni dobro doslo za full screen scroll rutinu.
Mozda cak i imam negdje na disketama... ali nemam vise niti c64 niti
drive. Otislo prije hrpu godina. :(

Te diskete bi trebalo procitati i backup-irati s PC floppy drive-om,
ima programa za PC koji mogu citati Commodore-ove diskete. Bilo bi
steta da se podaci izgube a nije ih tesko spremiti i ne zauzimaju
prakticki nikakav prostor na disku ili na nekom serveru.

[Nikolaj Lazic]

Dana Thu, 20 Jul 2017 05:20:16 +0200, Chupo <***@yahoo.com> napis'o:
[snip]

Post by Chupo
Te diskete bi trebalo procitati i backup-irati s PC floppy drive-om,
ima programa za PC koji mogu citati Commodore-ove diskete. Bilo bi
steta da se podaci izgube a nije ih tesko spremiti i ne zauzimaju
prakticki nikakav prostor na disku ili na nekom serveru.

Mislim da to ne bu islo samo tako. Ja sam imao 1541 drive koji je snimao
jednostrano. I onda okrenes disketu i snimas na drugu stranu. Nije koristio
onu rupu na disketi za sinkronizaciju brzine vrtnje, nego je to rijeseno
u samom driveu. Tak da nema sanse da se to procita u PC driveu.
Btw... pricam o 5.25" disketama. :)

[Chupo]

Post by Nikolaj Lazic
Mislim da to ne bu islo samo tako. Ja sam imao 1541 drive koji je snimao
jednostrano. I onda okrenes disketu i snimas na drugu stranu. Nije koristio
onu rupu na disketi za sinkronizaciju brzine vrtnje, nego je to rijeseno
u samom driveu. Tak da nema sanse da se to procita u PC driveu.
Btw... pricam o 5.25" disketama. :)

Pa da, o tim disketama i govorim. Postoje programi koji omogucavaju da
se Commodore-ove 5.25" diskete citaju s obicnim 5.25" floppy drive-om
kakvog koristi PC.

http://www.lemon64.com/forum/viewtopic.php?p=11488

https://en.wikipedia.org/wiki/Individual_Computers_Catweasel

Ako u Google upises:

reading c64 floppy diskettes with pc

dobiti ces jos puno rezultata.

Ovdje su dvije jako zanimljive price o reverse engineering-u 1541
drive-a koji je ustvari mini kompjuter i moze izvrsavati programe:

https://stackoverflow.com/a/374407/1324175

https://stackoverflow.com/a/374506/1324175

Taj isti covjek je napisao i vecinu koda od MAME drivera za Jolly Card
poker aparat koji je baziran na 6809, processoru slicnom 6502:

Jos od 2008. od kad sam upload-ao ta dva videa planiram disassemblirati
rutinu za duplanje :-) Inace sam imao pravi Jolly Card aparat i kad si
u service menu-u kvotu za omjer dobitka povisio na maximum se duplanje
prakticki nije moglo promasiti. Ti aparati interno imaju dva virtualna
aparata izmedju kojih se vlasnik moze trenutno prebacivati pa se kad se
za to pokaze potreba moze prebaciti s aparata koji 'daje' na aparat
koji 'uzima' :-)

Sta se tice floppy disketa, jos uvijek imam i 8" diskete koje smo u
srednjoj koristili na Cromemco System 3 kompjuterima:

http://oldcomputers.net/cromemco-system-three.html

[Nikolaj Lazic]

Dana Thu, 20 Jul 2017 16:06:45 +0200, Chupo <***@yahoo.com> napis'o:
[snip]

Post by Chupo
Sta se tice floppy disketa, jos uvijek imam i 8" diskete koje smo u
http://oldcomputers.net/cromemco-system-three.html

Imao doma jednoga cca godinu dana. Z80 i motorola unutra. Super masina u tom
trenutku.

[Nikolaj Lazic]

Post by Chupo
Pa da, o tim disketama i govorim. Postoje programi koji omogucavaju da
se Commodore-ove 5.25" diskete citaju s obicnim 5.25" floppy drive-om
kakvog koristi PC.
http://www.lemon64.com/forum/viewtopic.php?p=11488
https://en.wikipedia.org/wiki/Individual_Computers_Catweasel
reading c64 floppy diskettes with pc
dobiti ces jos puno rezultata.

Ma, je... ali sve se vrti o spajanju 1541 na PC. Za to treba imati drive. :)

Post by Chupo
Ovdje su dvije jako zanimljive price o reverse engineering-u 1541

To se sjecam... cak i isprobavao. On je imao 6502 unutra.
Ali jako malo memorije (ok, u odnosu na c64 :) ).

[Bruno Babic]

Post by Nikolaj Lazic
Mislim da to ne bu islo samo tako. Ja sam imao 1541 drive koji je snimao
jednostrano. I onda okrenes disketu i snimas na drugu stranu. Nije koristio
onu rupu na disketi za sinkronizaciju brzine vrtnje, nego je to rijeseno
u samom driveu. Tak da nema sanse da se to procita u PC driveu.
Btw... pricam o 5.25" disketama. :)

Ja sam slozio jednostavni paralelni port adapter s kojim se C64
kazetofon spojio na PC i onda je C64S (Slovenski) bio u stanju ucitavati
podatke s kazete. Na taj nacin sam i sacuvao svoj Atomix.

Ovdje cak pise da se moze na vise nacina spasiti sadrzaj kazete:
http://wav-prg.sourceforge.net/faq.html

Za pretpostaviti je da bi se tako nesto dalo napraviti i za drive, tu
pise da to ide:
http://dreamsteep.com/tutorials/general-tips-and-tutorials/251-transferring-commodore-64-disks-to-modern-formats.html

[Bruno Babic]

Post by Nikolaj Lazic

Post by Chupo

Post by Bruno Babic
P.S. ovo polako prelazi tematiku grupe pa mozda da nastavimo na mail?

Moze :-)

A, mozda ipak ne?

Hajde, onda ipak ne :)

Post by Nikolaj Lazic
Kak to da nije spomenut tasm na c64? To je tak fini assembler za c64.

Ja sam imao neki program koji se zvao "MONITOR 49152" i s njim sam sve
radio. Nije bilo kompajliranja nego pises direktno u RAM. Nista tasm,
nista snimanje text filea... cisti dump memorije na kazetu. Kada sam
skuzio tasm i slicne editore, onda sam se lupao u glavu :)

Post by Nikolaj Lazic
A, nulta strana na 6502 je tak super fora sa hrpom pointera koje mozes
vrtiti po zelji. Fino zamisljeno.
Meni dobro doslo za full screen scroll rutinu.
Mozda cak i imam negdje na disketama... ali nemam vise niti c64 niti
drive. Otislo prije hrpu godina. :(

Ja sam moj C64 poklonio braticu, on ga rashodovao na neki nacin. No, u
medjuvremenu sam, nostalgije radi, nabavio dva komada C64 jer su mi
naletjeli za neku sicu.

[Nikolaj Lazic]

Post by Bruno Babic

Post by Nikolaj Lazic

Post by Chupo

Post by Bruno Babic
P.S. ovo polako prelazi tematiku grupe pa mozda da nastavimo na mail?

Moze :-)

A, mozda ipak ne?

Hajde, onda ipak ne :)

Post by Nikolaj Lazic
Kak to da nije spomenut tasm na c64? To je tak fini assembler za c64.

Ja sam imao neki program koji se zvao "MONITOR 49152" i s njim sam sve
radio. Nije bilo kompajliranja nego pises direktno u RAM. Nista tasm,
nista snimanje text filea... cisti dump memorije na kazetu. Kada sam
skuzio tasm i slicne editore, onda sam se lupao u glavu :)

Da, monitor 49152 su cak objavili u nekom od casopisa... samo DATA i onda
finalni checksum. To sam prekucao i onda s frendom na kupici u parku
provjeravao par dana nakucanu data listu. :)
Nakon tjedan dana provjere (svaki dan po malo) sve bilo ok.
Stavio na floppy... i onda isao pregledavati neki program... startao nesto...
kaj mi je onda obrisalo BAM na floppyju.
Tada to nisam znao srediti. :(
Kasnije sam tja monitor 49152 skopirao iz jednog modula. :)

Post by Bruno Babic

Post by Nikolaj Lazic
A, nulta strana na 6502 je tak super fora sa hrpom pointera koje mozes
vrtiti po zelji. Fino zamisljeno.
Meni dobro doslo za full screen scroll rutinu.
Mozda cak i imam negdje na disketama... ali nemam vise niti c64 niti
drive. Otislo prije hrpu godina. :(

Ja sam moj C64 poklonio braticu, on ga rashodovao na neki nacin. No, u
medjuvremenu sam, nostalgije radi, nabavio dva komada C64 jer su mi
naletjeli za neku sicu.

:)
Pogledao na njuskalo... uf...

[Bruno Babic]

Post by Nikolaj Lazic

Post by Bruno Babic
Ja sam moj C64 poklonio braticu, on ga rashodovao na neki nacin. No, u
medjuvremenu sam, nostalgije radi, nabavio dva komada C64 jer su mi
naletjeli za neku sicu.

:)
Pogledao na njuskalo... uf...

Nazalost, clanovi retro grupe su nenamjerno uzrokovali rast cijena
starog hardvera.

Ja sam jedan C64 sa kazetofonom i nesto kazeta platio 120 kn, a za drugi
C64 sa kazetofonom, dva modula i printerom sam dao dva stara SCSI diska
od 10GB.

Sada su na njuskalu barem 300 kn i to ne kompletni nego im ili nesto
fali ili, kako napisu - ne znaju da li uopce radi. Smijesno.

[Bruno Babic]

Post by Chupo
Bas cu za vjezbu napraviti Atomix za Pac-Man hardware. Jedino moram
provjeriti da li vec ne postoji ista igra za MAME. Na YT vidim da osim

Ovo i mene zanima. Rado bih da vidim kako tocno Z80 radi, pa ako imas
volje i zivaca da pomalo usput objasnjavas sto, kako i zasto radis, ja
cu te rado poslusati (a pretpostavljam i ostali lurkeri na grupi).

BTW, napisao si u odgovoru Nikolaju da imas nekakvu kao razvojnu okolinu
(za Pacman) koja ti relativno lako omogucuje da nesto napravis i onda to
nesto pokrenes u MAME-u... ima sanse da ta razvojna okolina postane
javno dostupna?

[Chupo]

Post by Bruno Babic
Ovo i mene zanima. Rado bih da vidim kako tocno Z80 radi, pa ako imas
volje i zivaca da pomalo usput objasnjavas sto, kako i zasto radis, ja
cu te rado poslusati (a pretpostavljam i ostali lurkeri na grupi).

Opisati cu ovdje na grupi neke osnovne stvari ali detaljne opise cu
staviti u blog postove na blog kojega uskoro mislim pokrenuti.

Post by Bruno Babic
BTW, napisao si u odgovoru Nikolaju da imas nekakvu kao razvojnu okolinu
(za Pacman) koja ti relativno lako omogucuje da nesto napravis i onda to
nesto pokrenes u MAME-u... ima sanse da ta razvojna okolina postane
javno dostupna?

Prakticki sam samo iskoristio postojece alate (SjASMPlus ima jako
korisne dorektive i mogucnost koristenja Lua skripti) i napisao Java
programe koji podatke upisuju direktno u ROM file. Program za
generiranje sprite-a na osnovu 16x16 .bmp slike sam vec poslao u ovom
thread-u ali bez objasnjenja kako se je do tog algoritma doslo i kako
ga koristiti taj listing ne moze nekome previse pomoci pa moram
napisati i te detalje.

Ako bi bilo zainteresiranih bi se mogo napraviti pravi development kit
ko sta je recimo netko napravio na Out Run hardware:

http://tinyurl.com/y7u33zao

Ali za Pac-Man HW treba moci samo generirati Z80 kod koji ce biti
lociran na odredjenim adresama u 4 ROM cipa od po 4 KB, podatke za
tile-ove i sprite-ove u jos 2 ROM-a od po 4 KB, ROM od 32 byte-a s
opisom boja, ROM od 256 byte-ova za 64 palete od po 4 boje i jos dva
ROM-a od po 256 byte-ova sa po 8 sample-ova za generiranje zvuka.

Ako se koriste originalne palete i boje onda je u pocetku dok kod jos
ne zauzima vise od 4 KB dovoljno generirati samo jedan ROM file i za
pocetak modificirati nekoliko tile-ova i sprite-ova.

BTW, upravo sad sam se preko chat-a 'cuo' sa Zlatkom (on je u Viru na
godisnjem i bas krece u Zadar), bas mi je 'pricao' od kud se poznate i
reko je nek te pozdravim :-) Poslao sam mu link na ovaj thread i njegov
komentar je: 'Inace ovo o cemu pricate na forumu je za mene spansko
selo:-)' :-)

[Chupo]

Post by Bruno Babic
Ovo i mene zanima. Rado bih da vidim kako tocno Z80 radi, pa ako imas
volje i zivaca da pomalo usput objasnjavas sto, kako i zasto radis, ja
cu te rado poslusati (a pretpostavljam i ostali lurkeri na grupi).

Evo za pocetak kako sam si slozio razvojnu okolinu:

U jedan folder sam raspakirao najnoviji MAME (mame0187b_32bit.exe) i tu
sam stavio .bat file sa sadrzajem:

REM mame.exe -window -debug pacman
REM mame.exe -window pacman
mame.exe pacman

Ako je aktivna prva linija onda se pokrece debuggiranje, druga linija
pokrece emulaciju u prozoru a treca u full screen. Da bi se pokrenuli
ROM-ovi koji ne prolaze CRC i hash provjeru se MAME mora pokrenuti iz
komandne linije, ako se isti modificirani ROM-ovi pokrenu iz MAME
launcher-a onda pokretanje nece biti dozvoljeno.

U pacman.zip file-u za tu verziju MAME-a mora biti 10 ROM file-a i taj
file treba skinuti posebno jer distribucija ROM-ova s MAME-om nije
dozvoljena.

Nakon toga sam slozio radni folder za pisanje programa za Pac-Man
aparat i kreiranje pacman.6e ROM file-a u kojem se nalazi prvih 4 KB
koda za processor Z80. U taj sam folder stavio i originalni pacman.zip
file u kojem se nalazi svih 10 ROM file-ova.

Extenzija u imenu svakog od file-a inace oznacava fizicku lokaciju ROM
cipa na originalnoj maticnoj ploci od aparata. Na elektricnoj shemi
uredjaja su na svakoj strani oznake i cip u kojem se nalazi prvih 4 KB
koda je na lokaciji 6-E pa zato takva extenzija. ROM file-ovi su cisti
binarni file-ovi bez ikakvog header-a.

U tom folderu sam kreirao file pacman_src.zx i compile.bat file sa
sadrzajem:

@echo off
::echo Pocetak compile-iranja...
::echo.
sjasmplus.exe pacman_src.zx --lst=listing.zx
echo.
::echo Kraj compile-iranja
::echo.
pause

Extenziju .zx sam koristio zato jer sam SjASMPlus ranije koristio za
generiranje koda za ZX Spectrum pa sam naviko na tu extenziju. Za
editiranje source-a koristim staru verziju ConTEXT editora od Edena
Kirina (koji je godinama bio ovdje na news-ima na grupama za
programiranje) s dodanom definicijom za Z80 highlighter (jedino mi se
cini da sam negdje dodao i extenziju .zx tako da se highligter izabere
automatski).

Nakon sta kliknem na compile.bat se u istom folderu kreiraju file-ovi
pacman.6e duzine 4096 byte-ova i listing.zx u kojem je originalni
listing zajedno s opcode-ovima instrukcija i adresama koje je generirao
compiler a sta je jako korisno za debuggiranje napisanog koda s
debugger-om koji je ugradjen u MAME.

Nakon toga jednostano s drag'n'drop file pacman.6e povucem na file
pacman.zip a onda file pacman.zip samo povucem na folder roms unutar
foldera u kojem je instaliran MAME (normalno, kad kopiram .zip file
drzim Ctrl tako da Windows-i umjesto move naprave copy). To bi se lako
moglo automatizirati ali sve skupa traje jednu sekundu pa nisam za to
isao raditi skriptu ali kada ce mi generirani kod zauzimati vise ROM
file-ova cu u SjASMPlus dodati Lua skriptu za automatizaciju cijelog
procesa tako da ce se onda nakon compile ROM iste sekunde moci
pokrenuti u emulatoru.

I na kraju ostaje jos samo testni kod za Z80. Ovdje sam slozio rutine
za horizontalni i vertikalni ispis texta u centralnom dijelu ekrana i
za ispis u gornjem i donjem dijelu ekrana. Iako je organizacija video
memorije za ta dva podrucja drukcija (u centralnom cijelu su tile-ovi
organizirani u vertikalne blokove koji idu zdesna na lijevo a u gornjem
i donjem podrucju su ogranizirani u horizontalne blokove koji isto od
gore prema dole) sam za pisanje u jedan i drugi dio ekrana slozio istu
rutinu jer se moze primijetiti da pomak izmedju adresa u video RAM-u
koji u centralnom dijelu uzrokuje hozizontalni pomak - u gornjem i
donjem dijelu ekrana uzrokuje vertikalni pomak i obratno. S obzirom da
vertikalni pomak koji u centralnom dijelu ekrana uzorkuje pomak prema
dolje, u gornjem i donjem dijelu ekrana uzrokuje pomak prema lijevo,
morao sam u rutini uvesti jos jedan slucaj jer bi se text u gornjem i
donjem dijelu inace ispisivao zdesna na lijevo. Zvuci komlicirano ali
svakome tko ce analizirati organizaciju video RAM-a ce biti jasno o
cemu govorim.

U programu je i rutina za ispisivanje hex vrijednosti, placeholder-i za
RST rutine, interrupt rutina u kojoj se broje i ispicuju tick-ovi i
rutina za scroll jednog po jednog sprite-a na dnu ekrana jedan za
drugim preko ekrana prelaze tresnja, jagoda, breskva, zvono itd.) koji
su definirani u ROM-u pacman.5f

Ispod tick-ova se ispisuje i hex vrijednost s porta za ocitavanje
joystick-a i coin slot-ova (vrijednost se nece mijenjati prilikom
ubacivanja zetona jer sam byte maskirao tako da se mijenjaju samo
bitovi preko kojih se ocitava joystick).

Za one kojima ce kod biti cudan, SjASMPlus omogucava koristenje
lokalnih labela tako da se iste (brojcane) labele u kodu pojavljuju
vise puta a kada se koriste takve labele onda se smjer skoka oznacava s
dodatnim slovom - B(ack) ili F(orward).

Ovo je samo testni kod koji nije optimiziran:

TAB width = 10 karaktera

OUTPUT pacman.6e

wdg equ #50c0 ; watchdog timer
irqen equ #5000 ; interrupt request enable
ram equ #4c00 ; pocetak RAM-a
ramtop equ #4ff0 ; kraj RAM-a (zadnjih 16 byte-ova je
sprctrl)
vram equ #4000 ; video RAM
colram equ #4400 ; color RAM
sprctrl equ #4ff0 ; 8x2 byte-a nnnnnnxy (number - flip) <--
kraj RAM-a
sprcoords equ #5060 ; 8x2 bytes (x, y)

; sprctrl se moze i citati
; sprcoords se NE moze citati!!

in0 equ #5000 ; coin3 coin2 coin1 rack down right left
up
in1 equ #5040 ; upright start2 start1 service down right left
up

topleft equ vram + #03a0 ; gornji lijevi kut

; ************
; * variable *
; ************
; xpos equ ram ; #4c00
; ypos equ ram + #01
; col equ ram + #02 ; boja (paleta)
; printmode equ ram + #03 ; 0 = horizontalno, ostalo = vertikalno
; ticks equ ram + #04 ; 2 byte-a
; ; ram + #05
; tickslast equ ram + #06 ; 2 byte-a
; ; ram + #07
; c1 equ ram + #08 ; counter 1
; c1init equ ram + #09 ; counter 1 init

; drugi nacin definiranja variabli u RAM-u
map #4c00
x0 # 1
y0 # 1
col # 1 ; boja (paleta)
printmode # 1 ; 0 = horizontalno, 1 = vertikalno, 2 = vrh i
dno ekrana
ticks # 2 ; 2 byte-a
tickslast # 2 ; 2 byte-a
c1 # 1 ; counter 1
c1init # 1 ; counter 1 init
endvar # 1
DISPLAY " "
DISPLAY "KRAJ VARIABLI : ", /h, endvar, ", DUZINA : ", /d,
endvar - #4c00

; *************
; * konstante *
; *************
C1_INIT equ 2 ; counter za brzinu pomaka

org #0000

pocetak di
xor a
ld (irqen),a ; iskljuci vanjski interrupt
jr start

; **************
; * RST adrese *
; **************
; RST #08
FPOS #0008
org #0008
ret

; RST #10
FPOS #0010
org #0010
ret

; RST #18
FPOS #0018
org #0018
ret

; RST #20
FPOS #0020
org #0020
ret

; RST #28
FPOS #0028
org #0028
ret

; RST #30
FPOS #0030
org #0030
ret

; ********************
; * INTERRUPT RUTINA *
; ********************
; RST #38
FPOS #0038
org #0038
push hl
push de
push bc
push af
ld hl,ticks+1 ; nizi byte
ld a,(hl)
inc a ; povecaj broj tick-ova
ld (hl),a
jr nz,1F ; ako je 256
dec hl
inc (hl) ; povecaj i visi byte
1 ld hl,c1 ; counter 1
dec (hl)
jr nz,2F
ld a,(c1init)
ld (c1),a ; ponovo inicijaliziraj c1
ld hl,x0
dec (hl) ; pomakni sprite
ld a,(x0)
ld (sprcoords),a ; upisi novu koordinatu
or a ; ako je nula
jr nz,2F
ld a,(sprctrl)
add a,#04 ; sljedeci sprite
ld (sprctrl),a
call sprnum ; ispisi broj sprite-a
2 call joystick ; prikazi ulaz sa joystick-a
pop af
pop bc
pop de
pop hl
ei
reti ; vrati se iz interrupt rutine

; *********
; * START *
; *********

; nakon zadnje RST adrese
start ld sp,ramtop ; stack pointer na kraj RAM-a

ld hl,irqen ; resetiranje 74ls259
ld b,#08
xor a
loop1 ld (hl),a
inc l
djnz loop1

; resetiraj brojac tick-ova
ld hl,ticks
ld (hl),a
inc l
ld (hl),a
; reset counter-a
ld a,C1_INIT
ld (c1init),a ; inicijalna vrijednost brojaca
ld (c1),a ; trenutna vrijednost brojaca

ld a,#01 ; aktiviranje interrupt-a
ld (irqen),a ; ukljuci vanjski interrupt
im 1
ei
; kraj inicijalizacije

ld hl,topleft ; koordinate
ld de,msg ; pointer na text
xor a
ld (printmode),a ; horizontalno
inc a
ld (col),a ; paleta #01
push hl
push de
call print ; ispisi text
pop de ; jos jedanput isti text
pop hl ; na istom mjestu
ld a,#01
ld (printmode),a ; okomito
call print ; ispisi text
xor a
ld (printmode),a ; vrati na horizontalno
ld hl,vram + #0362 ; koordinate
ld c,#c9
call printhex ; ispisi broj
call movright
ld c,#af
call printhex
call sprtest ; prikazi sprite
jr loop

ld hl,vram ; fill video memorije
ld b,#04
loop3 ld (wdg),a
;ld a,#40
xor a
loop2 ld (hl),a
inc a
and #0f
inc l
jr nz,loop2
inc h
djnz loop3

ld b,#04 ; fill color memorije
loop5 ld (wdg),a
;ld a,#0f
ld a,#01
loop4 ld (hl),a
;inc a
inc l
jr nz,loop4
inc h
djnz loop5

loop call wdg_res
ld hl,vram + #0364
ld a,(ticks)
ld c,a
call printhex
call movright
ld a,(ticks+1)
ld c,a
call printhex
;call sprtest
jr loop ; kraj programa

; *************
; * subrutine *
; *************

; reset watchdog timer-a
wdg_res xor a
ld (wdg),a
ret

; print
; hl = adresa u video RAM-u
; de = pointer na text (#ff = kraj)
print ld a,(de) ; procitaj byte
cp #ff
ret z ; vrati se ako je kraj
ld (hl),a ; upisi byte u video RAM
;ld bc,#0400 ; offset do color RAM-a
;push hl
;add hl,bc ; izracunaj adresu
set 2,h ; 'izracunaj' adresu u color RAM-u
ld a,(col)
ld (hl),a ; podesi boju (paleta)
;pop hl
res 2,h ; hl opet pokazuje na video RAM
ld a,(printmode)
or a
jr z,2F ; ako je 0
dec a
jr z,3F ; ako je 1
inc l
jr 1F ; ako je 2 (vrh i dno ekrana)
3 inc l ; vertikalni pomak
jr 1F
2 ld a,l ; horizontalni pomak (hl -= #20)
sub #20
ld l,a
jr nc,1F
dec h
1 inc de
call wdg_res
jr print
; end print

; print hex
; hl = adresa u video RAM-u
; c = broj (registar se ne mijenja)
; hl na izlazu pokazuje na sljedecu lokaciju
printhex ld a,c
rra
rra
rra
rra
and #0f
ld (hl),a
;ld de,#0400
;push hl
;add hl,de
set 2,h ; adresa u color RAM-u
ld a,(col)
ld (hl),a
;pop hl
res 2,h ; hl opet pokazuje na video RAM
ld a,(printmode)
or a
jr z,1F
dec a
jr z,3F
dec l ; printmode 2 (vrh i dno ekrana)
jr 2F
3 inc l ; vertikalni pomak
jr 2F
1 call movright
2 ld a,c ; ponovo ucitaj broj
and #0f
ld (hl),a
;ld de,#0400
;push hl
;add hl,de
set 2,h ; color RAM
ld a,(col)
ld (hl),a
;pop hl
res 2,h ; video RAM (ako ce se pisati dalje)
ret
; end printhex

; movright
; horizontalni pomak (hl -= #20)
movright ld a,l
sub #20
ld l,a
jr nc,1F
dec h
1 ret

;sprite test
sprtest xor a ; nulti sprite
;ld a,#3e << 2 ; predzadnji sprite
;ld a,#10 << 2 ; sprite pune sirine
ld (sprctrl),a ; sprite 0
ld a,#01
ld (sprctrl+1),a ; paleta #01
ld a,239
ld (x0),a
ld (sprcoords),a
ld a,16
ld (y0),a
ld (sprcoords+1),a
; debug
;ld a,231
;ld (sprcoords),a
ret
; end sprite test

; joystick
joystick ld a,(in0) ; procitaj port 1
and #0f ; maskiraj down right left i right
ld c,a ; za printhex
ld hl,vram + #0366
jr printhex ; ret je u printhex
; end joystick

; print sprite number
sprnum or a ; obrisi carry flag
rra
rra
ld c,a ; za printhex
ld a,2 ; vrh ili dno ekrana
ld (printmode),a ; vertikalno je na dnu horizontalno
ld hl,vram + #0010 ; drugi red sredina na dnu
call printhex
xor a
ld (printmode),a ; horizontalno pisanje po glavnom ekranu
ret

msg byte "***@WAS@HERE"
defb #ff
kraj

; **************************************************

FPOS #0fff ; ROM ima 4096 byte-ova
org #0fff
last byte #c9
romend

display " "
display "GRESAKA : ", /d, _ERRORS
display "UPOZORENJA : ", /d, _WARNINGS
display "DUZINA PROGRAMA: ", /a, kraj - pocetak, " bytes"
display "DUZINA ROM-a : ", /a, romend - pocetak, " bytes"
display " "

[Chupo]

Post by Chupo
res 2,h ; hl opet pokazuje na video RAM
ld a,(printmode)
or a
jr z,2F ; ako je 0
dec a
jr z,3F ; ako je 1
inc l ; <---- ovdje je greska
jr 1F ; ako je 2 (vrh i dno ekrana)

Ispravak, ovaj dio print rutine mora izgledati ovako:

res 2,h ; hl opet pokazuje na video RAM
ld a,(printmode)
or a
jr z,2F ; ako je 0
dec a
jr z,3F ; ako je 1
dec l ; ako je 2 (vrh i dno ekrana)
jr 1F

Logika mora biti ista ko u printhex a na ovoj se slici lijepo vidi kako
se adrese u character RAM-u mapiraju na ekran:

http://umlautllama.com/projects/pacdocs/screen/

U plavom dijelu ekrana povecavanje adrese za 1 znaci pomak prema dolje
a smanjivanje adrese za 32 je pomak desno.

U ljubicastim podrucjima ekrana povecavanje adrese za 1 znaci pomak
prema lijevo a smanjivanje adrese za 32 je pomak prema gore.

Ako se u plavom dijelu ekrana text ispisuje horizontalno onda se adrese
nakon svakog slova moraju smanjivati za 32 a ako se pise vertikalno
onda se moraju povecavati za 1. A u ljubicastim podrucjima se za
horizontalno pisanje adrese moraju smanjivati za 1.

[Chupo]

Post by Chupo
movright ld a,l
sub #20
ld l,a
jr nc,1F
dec h
1 ret

Evo vrlo jednostavnog ali zanimljivog dijela koda. Ocito sam pisao
rutinski pa s jr nc bezveze skacem na instrukciju ret. Bolji kod bi
vjerojatno bio:

movright ld a,l
sub #20
ld l,a
ret nc
dec h
ret

Medjutim, sta ako to ne bi bio kraj rutine pa se ne moze koristiti
instrukcija ret a treba izbjeci instrukciju za skok? Jedan od razloga
zasto bi u nekom slucaju moglo biti pozeljno izbjeci instrukciju za
skok je jer joj je vrijeme izvrsavanja razlicito u slucajevima ako je
uvjet ispunjen i ako nije a to bi moglo zakomplicirati rutinu koja mora
imati timing tocan do na 1 T stanje pa onda moze biti pozeljno da svaki
prolaz trosi tocno isti broj taktova. U interrupt rutini koja ceka da
elektronski snop stigne na pocetak tocno odredjenog reda svaki prolaz
kroz petlju mora trajati do na takt isto vremena i u tom bi slucaju
rutina mogla izgledati npr. ovako:

movright ld a,l
sub #20
ld l,a
ld a,h
sbc #00
ld h,a
ret

Ovdje se od A registra oduzima nula ali se u obzir uzima i carry flag.

Od HL bi se 32 moglo oduzeti i ovako:

ld de,#20
or a
sbc hl,de ; sub hl,de ne postoji

ali to se moze koristiti samo ako se smije promijeniti DE. Ako je to
dozvoljeno onda se ista stvar moze jos elegantnije postici ovako:

ld de,-#20
add hl,de

jer u tom slucaju ne treba resetirati carry flag.

I ostatak koda kojega sam napisao se moze dosta poboljsati ali trenutno
samo testiram kako hardware funkcionira pa ne obracam preveliku paznju
na optimizaciju. Potpuno optimizirani kod bi izgledao kao da nema veze
s ovim sta je napisano trenutno.

[Bruno Babic]

Post by Chupo
Medjutim, sta ako to ne bi bio kraj rutine pa se ne moze koristiti
instrukcija ret a treba izbjeci instrukciju za skok? Jedan od razloga
zasto bi u nekom slucaju moglo biti pozeljno izbjeci instrukciju za
skok je jer joj je vrijeme izvrsavanja razlicito u slucajevima ako je
uvjet ispunjen i ako nije a to bi moglo zakomplicirati rutinu koja mora
imati timing tocan do na 1 T stanje pa onda moze biti pozeljno da svaki
prolaz trosi tocno isti broj taktova. U interrupt rutini koja ceka da
elektronski snop stigne na pocetak tocno odredjenog reda svaki prolaz
kroz petlju mora trajati do na takt isto vremena i u tom bi slucaju

Uzmi u obzir da nemam iskustva sa Z70, pa mi moras malo detaljnije
pojasniti ovu pricu. Jasno mi je da postoji video RAM i da ce ono sto je
u njemu biti prikazano na ekranu, ali s obzirom na to da nemas
hardverske spriteove, onda mi nije jasno kako ustvari crtas konkretan
sprite? Odnosno, zbunjuje me to sto spominjes inettrupt za svaku liniju
ekrana, ja bih ocekivao da se interrupt dogodi kada iscrtavanje dodje do
dna ekrana i onda iscrtas spriteove po ekranu dok se el. snop vraca na
pocetak ekrana.

P.S. nebi me iznenadilo da je to sve prekomplicirano za objasniti
pisanjem, ali probaj :)

[Chupo]

Post by Bruno Babic
Uzmi u obzir da nemam iskustva sa Z70, pa mi moras malo detaljnije
pojasniti ovu pricu. Jasno mi je da postoji video RAM i da ce ono sto je
u njemu biti prikazano na ekranu, ali s obzirom na to da nemas
hardverske spriteove, onda mi nije jasno kako ustvari crtas konkretan
sprite? Odnosno, zbunjuje me to sto spominjes inettrupt za svaku liniju
ekrana, ja bih ocekivao da se interrupt dogodi kada iscrtavanje dodje do
dna ekrana i onda iscrtas spriteove po ekranu dok se el. snop vraca na
pocetak ekrana.
P.S. nebi me iznenadilo da je to sve prekomplicirano za objasniti
pisanjem, ali probaj :)

Jednostavno je to za objasniti ali je *vrlo* komplicirano za
isprogramirati :-)

Da ne bude zabune, hardware-ske sprite-ove nije imao Spectrum a Pac-Man
hardware ih ima. Na Pac-Man hardware-u se sprite-ovi kontroliraju z par
byte-ova, jedan kontrolira broj sprite-a i zrcaljenje po x i y osi a
par byte-ova kontrolira koordinate.

To da se na Spectrumu 'sprite' ovi moraju iscrtavati programski ne
znaci da se mora koristiti ova metoda koju sam opisao - gdje bi se
cekalo da elektronski snop stigne na odredjeno mjesto. Naprotiv,
sprite-ovi se moraju iscrtati cim je brze moguce, prije nego
elektronski snop 'pregazi' mjesto na koje se crta jer bi se u tom
slucaju pojavio tearing - dio slike bi bio iz proslog frame-a a dio iz
trenutnog.

Recimo ako je slicica visine 16 pixela a elektronski snop je vec stigo
do pete linije unutar sprite-a - ako bi se video RAM update-ao tek u
tom trenutku onda bi prvih 5 linija u tom frame-u ostalo nepromijenjeno
a ostalih 11 linija bi se update-alo i ako se sprite krece bi ga to u
tom frame-u na pedesetinku sekunde izduljilo ili skratilo po visini, a
ako se sprite ne krece nego se samo update-a animacija onda bi jedan
cijeli frame prvih 5 linija bila iz jednog sprite-a a ostalih 11 iz
sljedeceg frame-a animacije.

To se moze sprijeciti na par nacina. Ili se mora koristiti jako brza
rutina koja ce video RAM update-ai u interrupt-u prije nego elektronski
snop stigne u podrucje ekrana. Vrijeme koje je na raspolaganju je
vrijeme za povratak snopa na vrh ekrana nakon VBLANK + vrijeme za
iscrtavanj border-a koji je iznad ekrana s grafikom.

Ako je grafika komplicirana onda rutina ne moze biti dovoljno brza pa
se izvan interrupt-a crta u frame buffer a onda se unutar interrupt-a
tak blok brzo prebaci na odgovarajuce mjesto. Z80 ima instrukcije za
pomicanje bloka podataka (LDIR i slicne) ali onda treba u RAM-u imati
kopiju video RAM-a.

Ekran se moze update-ati i tako da se van interrupt rutine stavi
instrukcija HALT (koja ceka interrupt) pa se onda ekran brzo update-a
izvan interrupt rutine, ali u tom slucaju interrupt rutina mora biti
jako kratka da ne potrosi previse vremena jer ce se nakon HALT najprije
izvrsiti ona a tek onda ce se nastaviti izvrsavanje glavnog programa.

U dosta ranih komercijalnih igri za Spectrum se moze vidjeti da su te
rutine napravljene dosta lose i zato je grafika trzava.

Ovo o cemu sam govorio, kada rutina mora cekati elektronski snop, se
koristi u drugim slucajevima. Prvi slucaj je da bi se boja border-a
promijenila u tocno odredjenoj liniji tako da se ta linija spoji sa
sadrzajem ekrana. Recimo ako se hoce nacrtati horizont preko cijelog
ekrana ukljucujui i border. Na Spectrumu sliku iscrtava ULA a boja
border-a se kontrolira pomocu najniza 3 bita upisanih na port 254 za
sta se koristi recimo:

OUT (#FE), A

Na taj se nacin informacija upisuje direktno u ULA-u i boja koju snop
iscrtava po border-u se promijeni trenutno, bez obzira na kojem je
mjestu snop. Ako je snop iznad ekrana onda se moze vidjeti na kojem se
je mjestu nalazio u trenutku kad se je izvrsila OUT instrukcija. To se
moze koristiti za odokativno 'mjerenje' trajanja interrupt rutine i
upravo sam to koristio ovdje:

http://youtu.be/eGDLdf3nZL0

Ovo gdje na vrhu titra plavi dio bordera je indikacija trajanja
interrupt rutine. Jer na pocetku interrupt rutine boju boder-a
postavljam na cyan a na krajuju vracam u bijelu.

S obzirom da trajanje svake pojedine interrupt rutine ovisi o raznim
petljama pa nije konstantno, mjesto na kojem se elektronski snop nalazi
na izlasku iz rutine se of frame-a do frame-a mijenja. Ako bi se
napravila rutina koja bi svaki put, bez obzira na petlje trajala do u
na takt isto vremena, onda bi plavi dio na vrhu ekrana bio savrseno
stabilan a ako bi trajanje rutine bilo jos doze onda bi linija u kojoj
se boja border-a mijenja bila u podrucju ekrana. Da bi se tova linija u
border-u savrseno spojila s necim sta je nacrtano na ekranu, timing
kada ce se izvrsiti OUT instrukcija mora biti savrsen - to se mora
desiti za vrijeme horizontalnog povratka snopa nakon sta se iscrta
linija iznad ciljne. Cim je linija koju treba povuci kroz border nize,
to ce interrupt rutina morati duze cekati pa ce ostati manje vremena za
sve ostale stvari - a vrlo je tesko napraviti rutine koje taktove trose
precizno a ipak rade korisne stvari.

Iscrtavanje svake linije ekrana traje tocno 224 T stanja a trajanja Z80
instrukcija su u rasponu od 4 do 23 T stanja pa ispada da bi se boja
border-a mogla promijeniti i vise puta unutar jedne linije (recimo u
dijelu na vrhu iznad ekrana) i na taj nacin iscrtati neki text. Da bi
se to postiglo se mora unaprijed pripremiti blok byte-ova koji ce se
poslati na port 254 i onda se koriste genijalni trikovi da bi se to
uspjelo napraviti dovoljno brzo pa da se dobiju cim krace horizontalne
linije - jer cim su linije krace je rezolucija veca.

Drugi slucaj kada se mora tocno cekati da elektronski snop stigne na
odredjeno mjesto je u rutinama koje omogucavaju da Spectrum ima vecu
rezoluciju boje nego sta mu to hardware dozvoljava. Pixeli se na
Spectrumu ne prikazuju tako da bi svaki pixel imao odredjeni broj
bitova a o kojem broju bi ovisio ukupni broj mogucih boja nego pixeli
uvijek imaju 1 bit po pixelu a boje se kontroliraju preko attributa
koji se nalaze iza video RAM-a koji kontrolira pixele. Svaki atribut
kontrorira blok od 8x8 pixela unutar kojega se mogu koristiti samo
dvije boje (INK i PAPER).

Recimo na adresi 16384 (ekran) + 6144 (duzina ekrana) = 22528 se do
adrese 23295 nalazi 768 atributa nalaze atributi s bojama za svaki blok
od 8x8 pixela. Na adresi 22528 je opis boja za blok pixela u gornjem
lijevom uglu. Ako se u interrupt rutini poceka dok elektronski snop
stigne do recimo kraja cetvrtog reda pixela ekrana pa se onda brzo
promijeni sadrzaj na adresi 22528 onda ce prva cetiri reda tog bloka
pixela imati prve dvije boje a druga 4 reda ce imati druge dvije boje
pa ce tako unutar bloka od 8x8 pixela biti prikazano vise boja nego sta
to hardware dozvoljava.

Ovo sta sam opisao je prilicno tesko i realizirati a ako se ove dvije
stvari (crtanje po border-u i promjena attributa ekrana u tocno
odredjenom trenutku) iskombiniraju onda se stvari *stvarno* pocinju
komplicirati :-) A ako se onda na sve to doda i da je ovo sam opis
principa a u stvarnosti se ne mijenja samo jedan attribut nego treba
promijeniti 32 attributa (jedan red), paziti da se sve promjene dese
prije nego elektronski snop 'pregazi' lokaciju u koju se podatak
upisuje (a snop je samo par desetina pixela lijevo od te lokacije) i da
istovremeno rutina mora uvijek trositi tocno do na takt 224 T stanja po
liniji, onda je jasno zasto su takvi programi koji to rade kvalitetno
napravljeni tek pod kraj osamdesetih ili cak tek u jos novije vrijeme
od 2000. na dalje.

Ono sta pretpostavljam (a ne mogu ispitati jer nemam originalni aparat
a MAME ne emulira njegov video hardware na dovoljno niskom nivou) je da
bi se slicne tehnike mogle koristiti i na Pac-Man hardware-u da bi se
prikazalo vise od osam sprite-ova ili da bi se postiglo vise od 4 boje
unutar jednog tile-a. Vec sam i napisao rutinu za koju sam skoro
siguran da bi na pravom aparatu omogucila vise od 4 boje po tile-u pa
cu ju poslati nekome tko ima originalni Pac-Man i zna sprziti EEPROM-e.

Ovaj covjek ocito ima i originalni uredjaj a zna i kako u ROM-ove
ubaciti svoje podatke ali izgleda da mi ne vjeruje da je to sta sam
opisao moguce :-)

http://youtu.be/4-o57DPCt8k

Odlican opis rada ULA-e (a i jos puno toga) nalazi se ovdje:

http://www.worldofspectrum.org/faq/reference/48kreference.htm

Ako se u Find upise:

224 T states

se moze odma pronaci opis iscrtavanja linija.

[Bruno Babic]

Ima kakvog napretka?

Bio sam na godisnjem pa nisam bas pratio newse :)

[Chupo]

Post by Bruno Babic
Ima kakvog napretka?
Bio sam na godisnjem pa nisam bas pratio newse :)

Zadnje vrijeme nisam imao dosta vremena ali u svakom slucaju cu za
vjezbu napraviti Atomix za Pac-Man HW pa cu onda prouciti Scramble
hardware i probati napraviti nesta za njega.

U medjuvremenu sam se malo bavio s 1-bit zvukom jer sam prije jedno
pola godine poceo raditi rutinu za generiranje zvuka na mikrokontroleru
a oduvijek sam proucavao i razne algoritme za generiranje zvuka na
Spectrumu pa sam neki dan primijetio da su napravljeni programi koji
simuliraju Spectrumove rutine na Arduino-u i koriste originalne podatke
od pjesama ali je autor napisao da postoji problem kojega ne moze
rijesiti pa me je to odma zaintrigiralo tako da sam istovremeno rijesio
taj problem:

http://randomflux.info/1bit/viewtopic.php?pid=1423#p1423

i odma sam - s obzirom da nemam Arudino :-) - napravio port za
ATmega128 i bare metal ATmega328 (u Arduino-u se koristi isti taj
mikrokontroler).

Autor tog foruma je covjek koji je osnovao Irrlicht Project a iz ovoga
tutoriala za pisanje rutina za generiranje zvuka na Z80 se moze jako
puno nauciti:

http://randomflux.info/1bit/viewtopic.php?id=21

Bez tih stvari je skoro nemoguce analizirati disassemblirane rutine za
generiranje zvuka na Spectrumu.

[Bruno Babic]

Post by Chupo
Autor tog foruma je covjek koji je osnovao Irrlicht Project a iz ovoga
tutoriala za pisanje rutina za generiranje zvuka na Z80 se moze jako

Ako sam dobro shvatio, ta rutina za zvuk se okaci na neki interrupt koji
se onda poziva u nekim redovitim intervalima? Rutina pamti sto je do
tada odradila pa nastavlja dalje u odnosnu na prethodni prolaz?

[Chupo]

Post by Bruno Babic
Ako sam dobro shvatio, ta rutina za zvuk se okaci na neki interrupt koji
se onda poziva u nekim redovitim intervalima? Rutina pamti sto je do
tada odradila pa nastavlja dalje u odnosnu na prethodni prolaz?

Da, ova verzija za mikrokontroler. S obzirom da je u C-u nemoguce
napisati kod koji bi u svakom prolazu trosio isti broj T stanja se
koristi timer koji generira interrupt-e u pravilnim vremenskim
razmacima. U glavnom programu se parsiraju podaci a u Timer 2 output
compare match interrupt-u se na zvucniku generiraju klikovi na isti
nacin kako bi ih generirala rutina na Spectrumu koja ne koristi
interrupt nego radi punom brzinom ali je napisana tako da u svakom
prolazu, bez obzira na grananja, uvijek trosi isti broj taktova.

Moglo bi se reci da je takav nacin pisanja programa varanje i autor
foruma je reko da bi i na mikrokontroleru htio napraviti 'pravu' rutinu
pisanu u assembleru koja bi radila na potpuno isti nacin ko originalne
rutine za Spectrum. Na AVR mikrokontrolerima ce to biti puno lakse
napraviti jer 90% instrukcija traje samo 1 ili dva takta a na Spectrumu
instrukcije traju od 4 do 23 takta pa nije jednostavno napraviti rutinu
koja ce uvijek trositi jednak broj taktova.

Interrupt se na Spectrumu za tu svrhu nije mogo koristiti jer
frekvenciju interrupta odreduje ULA i tako da se interrupti, kao i na
vecini kompjutera iz osamdesetih, generiraju s VBLANK i frekvencija je
onda samo 50 Hz a neke rutine za zvuk na Spectrumu impulse generiraju
cak i s frekvencijama vecim od 400 (cetiristo!!) kHz :-)) Iako se na
prvi pogled cini da frekvencija toliko iznad praga cujnosti nema
smisla, ako se prouci princip na kojem se u takvim rutinama dobiva neki
valni oblik u cujnom podrucju onda to ima smisla. Takve frekvencije su
i na samoj granici sta se tice brzine kojom se uopce na Spectrumu moze
mijenjati stanje na portu 254 (jer 3.5 MHz/400 kHz = samo 8 taktova).

Na mikrokontroleru koji ima skoro 5 puta brzi takt a instrukcije mu u
prosjeku trosiju 10 puta manje taktova i jos k tome ima i vise timer-a
od kojih svaki omogucava generiranje vise vrsta interrupt-a nije
problem takav nacin generiranja zvuka simulirati s rutinom u C-u koja u
glavnom programu za sinhronizaciju kanala koristi dodatnu variablu, ali
pisanje takve rutine na Spectrumu spada u umjetnost :-)

Dodatna otezavajuca okolnost je da na ranim modelima Spectruma prilikom
pisanja u port 254 ULA uzrokuje dodatno kasnjenje koje se periodicki
mijenja - pa je onda zbog toga uvjet da bi rutina uvijek trajala
jednaki broj taktova da je zbroj taktova izmedju dva pisanja u port 254
djeljiv s 8 :-) Ako se tome doda i da se za jedan prolaz kroz rutinu na
raspolaganju ima samo oko 250 taktova, onda je sve skupa jos 'malo'
kompliciranije i to su razlozi zasto su se prve kvalitetne rutine za
visekanalni zvuk pocele javljati tek jedno 4-5 godina od izlaska
Spectruma. Mislim da je prvi 'pravi' dvokanalni zvuk bio u Manic Mineru
i to je zvucalo jako lose:

ali je u svim casopisima opisivano kao 'nevjerojatno'. Prva kvalitetna
rutina koje se sjecam je bila ova:

U ono vrijeme sam ju analizirao valjda godinu dana :-)

Ovo je recimo primjer rutine gdje zvuk na emulatorima nije ni blizu
onoga kako se cuje u originalu:

Kroz Spectrumov zvucnik se cuje zvuk gajdi ali u emulatorima se cuje
potpuno drukciji zvuk. Objasnjenje je ovdje:

http://youtu.be/nAlHlpzzrKo

<start copy/paste>
zx beeper routines operate with up to 400 kHz, which is impossible to
reproduce accurately on a 44.1 kHz soundcard.
<end copy/paste>

To je napisao upravo ovaj isti covjek koji je autor foruma na kojega
sam ti dao link :-)

[Chupo]

Post by Chupo
Kroz Spectrumov zvucnik se cuje zvuk gajdi ali u emulatorima se cuje

Dvaput sam kopirao isti link, ovo je ispravan:

http://tinyurl.com/ckftaow

[Nikolaj Lazic]

Post by Chupo
U medjuvremenu sam se malo bavio s 1-bit zvukom jer sam prije jedno
pola godine poceo raditi rutinu za generiranje zvuka na mikrokontroleru
a oduvijek sam proucavao i razne algoritme za generiranje zvuka na
Spectrumu pa sam neki dan primijetio da su napravljeni programi koji
simuliraju Spectrumove rutine na Arduino-u i koriste originalne podatke
od pjesama ali je autor napisao da postoji problem kojega ne moze
rijesiti pa me je to odma zaintrigiralo tako da sam istovremeno rijesio

I onda me to podsjetilo na Wham! The music box na ZXu. Cak je i ok radilo...

[Chupo]

Post by Nikolaj Lazic
I onda me to podsjetilo na Wham! The music box na ZXu. Cak je i ok radilo...

Ima i Music Box engine kojega je napravio autor iz Hrvatske a zvuk je
bio toliko dobar da je Music Box jedan od deset 1-bit engine-a koje
podrzava Beepola. To je ustvari rutina iz YU The Music Box programa:

http://www.worldofspectrum.org/infoseekid.cgi?id=0008487

kojega je napravio Sasa Pusica. S tim da se taj engine u Beepola-i zove
Music Studio a jedan drugi engine se zove Music Box:

http://freestuff.grok.co.uk/beepola/help/credits.html

Beepola se moze skinuti ovdje:

http://freestuff.grok.co.uk/beepola/

Pomocu Beepola-e se mogu na PC-u generirati razlicite podrzane rutine
za generiranje zvuka na Spectrumu ili .tap file kojega se moze ucitati
u svaki Spectrum emulator ili u pravi Spectrum a za vrijeme izrade
muzike se zvuk emulira i na PC-u.

Ovo je recenzija Yu The Music Box-a / Music Stuidio-a:

[Nikolaj Lazic]

Post by Chupo

Post by Nikolaj Lazic
I onda me to podsjetilo na Wham! The music box na ZXu. Cak je i ok radilo...

Ima i Music Box engine kojega je napravio autor iz Hrvatske a zvuk je
bio toliko dobar da je Music Box jedan od deset 1-bit engine-a koje

Zar nije i scream tracker radio isto 1bitno na PCu preko internog zvucnika?
Sjecam se da smo mi prvo sve slusali preko internog zvucnika, a onda
radili DA konvertor za paralelni port. To je bilo davni prije ikakvih
tvucnih kartica.
I, bilo je ok imati 2 LPT porta za stereo zvuk. :)

[Chupo]

Post by Nikolaj Lazic
Zar nije i scream tracker radio isto 1bitno na PCu preko internog zvucnika?
Sjecam se da smo mi prvo sve slusali preko internog zvucnika, a onda
radili DA konvertor za paralelni port. To je bilo davni prije ikakvih
tvucnih kartica.
I, bilo je ok imati 2 LPT porta za stereo zvuk. :)

Je, ja sam 1991. na 386-ici imao 8 bit Sounblaster ali i driver preko
kojega su mod player-i svirali preko zvucnika.

Bas sam neki dan probao na netu naci on stare mod file-ove koji su
kruzili po YU prostorima i naso sam samo ovo:

http://modli.rs/music/MODmusic/mod_music.html

Das Boot imam jos iz tih vremena na hard disku od 252 MB kojega sam
imao u 386-ici. Prije 2 godine sam probao kompjuter zboot-ati s tog
diska ali je to FAT16 i nije radilo pa sam napravio raw backup svih
podataka i s hex editorom vidim imena file-ova ali jos nisam skuzio
kako da te podatke mount-am pa da mogu pristupati file-ovima.

[Nikolaj Lazic]

Post by Chupo
Je, ja sam 1991. na 386-ici imao 8 bit Sounblaster ali i driver preko
kojega su mod player-i svirali preko zvucnika.
Bas sam neki dan probao na netu naci on stare mod file-ove koji su
http://modli.rs/music/MODmusic/mod_music.html
Das Boot imam jos iz tih vremena na hard disku od 252 MB kojega sam
imao u 386-ici. Prije 2 godine sam probao kompjuter zboot-ati s tog
diska ali je to FAT16 i nije radilo pa sam napravio raw backup svih
podataka i s hex editorom vidim imena file-ova ali jos nisam skuzio
kako da te podatke mount-am pa da mogu pristupati file-ovima.

Stavis VirtualBox i instaliras Linux. I onda mountas taj file kao disk.
Kad dodes do toga, onda detaljnije upute. :)

[Chupo]

Post by Nikolaj Lazic
Stavis VirtualBox i instaliras Linux. I onda mountas taj file kao disk.
Kad dodes do toga, onda detaljnije upute. :)

Tako se moze mount-ati raw file? Mislim da sam image napravi s Raw Copy
s Hiren's Boot DVD-a. Htio bi to nekako konvertirati u FAT16 image s
kojim bi se u VirtualBox-u s tog diska moglo boot-ati i nakon toga
pokretati programe, gore su i Win 3.1, Comanche: Maximum Overkill, Star
Wars: Tie Fighter, The Incredible Machine, DOOM i jos hrpa programa.

[Bruno Babic]

Post by Chupo
Tako se moze mount-ati raw file? Mislim da sam image napravi s Raw Copy
s Hiren's Boot DVD-a. Htio bi to nekako konvertirati u FAT16 image s
kojim bi se u VirtualBox-u s tog diska moglo boot-ati i nakon toga
pokretati programe, gore su i Win 3.1, Comanche: Maximum Overkill, Star
Wars: Tie Fighter, The Incredible Machine, DOOM i jos hrpa programa.

Trebao bih negdje imati P2 baziranu plocu i procesor (trebali bi biti
ispravni) pa ako bas ne uspijes nikako drukcije, mogu ti to dati da
bootas kako treba.

[Chupo]

Post by Bruno Babic
Trebao bih negdje imati P2 baziranu plocu i procesor (trebali bi biti
ispravni) pa ako bas ne uspijes nikako drukcije, mogu ti to dati da
bootas kako treba.

Tnx! :-) Probati cu jos najprije nekako konvertirati raw image kojega
sam napravio. Moja maticna inace ima i IDE konektore i disk je citljiv
ali izgleda da BIOS ne omogucava boot-anje s FAT16 diskova.

Imam jos uvijek i tu staru 386-icu (Cyrix na 40 MHz) iz koje je taj
hard disk izvadjen ali nisam siguran da li nakon toliko godina jos
uvijek radi, moram provjeriti jos i to.

[Nikolaj Lazic]

Post by Chupo

Post by Nikolaj Lazic
Stavis VirtualBox i instaliras Linux. I onda mountas taj file kao disk.
Kad dodes do toga, onda detaljnije upute. :)

Tako se moze mount-ati raw file? Mislim da sam image napravi s Raw Copy
s Hiren's Boot DVD-a. Htio bi to nekako konvertirati u FAT16 image s
kojim bi se u VirtualBox-u s tog diska moglo boot-ati i nakon toga

Image bi se mozda i mogao mountati kao disk za boot VirtualBoxa.
Ali, ja bih prvo napravio kopiju. :)
Mislim da cak i ne treba nista konvertirati. Samo mu se to napikne kao
image s kojeg starta. A, mozda bi i igrice radile... ali to nisam nikad
isprobavao.
Meni je VirtualBox dobro dosao za voziti virtualnu masinu s Linuxom za
jedan printer koji vise ne radi pod Windblowsima. :)
Ali, sada kao mrezni printer radi savrseno. :)

Post by Chupo
pokretati programe, gore su i Win 3.1, Comanche: Maximum Overkill, Star
Wars: Tie Fighter, The Incredible Machine, DOOM i jos hrpa programa.

[Nikolaj Lazic]

Post by Nikolaj Lazic

Post by Chupo

Post by Nikolaj Lazic
Stavis VirtualBox i instaliras Linux. I onda mountas taj file kao disk.
Kad dodes do toga, onda detaljnije upute. :)

Tako se moze mount-ati raw file? Mislim da sam image napravi s Raw Copy
s Hiren's Boot DVD-a. Htio bi to nekako konvertirati u FAT16 image s
kojim bi se u VirtualBox-u s tog diska moglo boot-ati i nakon toga

Image bi se mozda i mogao mountati kao disk za boot VirtualBoxa.
Ali, ja bih prvo napravio kopiju. :)
Mislim da cak i ne treba nista konvertirati. Samo mu se to napikne kao
image s kojeg starta. A, mozda bi i igrice radile... ali to nisam nikad
isprobavao.

Ili... skines recimo Debian Live, stavis na USB, bootas s USBa, mountas
particiju gdje ti je taj file... pa mountas taj file i onda kopiras stvari
na win particiju. Za pocetak.

[Nikolaj Lazic]

Post by Chupo

Post by Nikolaj Lazic
Stavis VirtualBox i instaliras Linux. I onda mountas taj file kao disk.
Kad dodes do toga, onda detaljnije upute. :)

Tako se moze mount-ati raw file?

Da, particije isto mozes dohvatiti unutar imagea...

https://ubuntuforums.org/showthread.php?t=1576011

[Chupo]

Post by Nikolaj Lazic
Da, particije isto mozes dohvatiti unutar imagea...
https://ubuntuforums.org/showthread.php?t=1576011

Probati cu, backup tog starog hard-a mi se nalazi na disku koji
trenutno nije u kompjuteru pa cu ga jedan dan prebaciti u PC.

Dok sam radio backup s tog diska iz 1991. godine sam, nakon sta sam
disk prikljucio na maticnu plocu, mislio da nema sanse da ce se ista
procitati jer je zvuk bio kao da ce se hard disk raspasti :-) Prije
toga disk nije radio oko 20 godina ali je ipak kopiranje svih podataka
proslo bez jedne jedine greske.

[Bruno Babic]

Post by Chupo
Je, ja sam 1991. na 386-ici imao 8 bit Sounblaster ali i driver preko
kojega su mod player-i svirali preko zvucnika.

Kad ste vec kod zvuka, evo jedan link na player kojeg sam radio sa
prijateljem. Izmedju ostalog ima i driver za PC speaker (kad smo vec kod
1-bit enginea).

http://www.iscro.com/stuff/retro/oplay/oplay105.zip

100% pure x86 assembler... trebas imati VESA mod na grafickoj kartici da
bi radio. Isprobano radi pod DOSBox-om, SB 16 emulacijom na 22050Hz, S3
graficka kartica.

Player je nastao kao nusproizvod jer smo se namucili za igru da
napravimo dovoljno brz MOD player pa smo ga onda iskoristili da jos
jedanput pokupimo neku nagradu na izlozbi studentskih radova :)

U igri mozes cuti engine playera u praksi, na mojoj 306-tici na 25MHz je
zauzimao oko 3-5% CPU-a za 4 kanalni MOD file.

http://www.iscro.com/stuff/retro/bluppo/bluppoc.zip

I igra radi bez problema pod DOSBox-om sa istim postavkama.

[Chupo]

Post by Bruno Babic
Kad ste vec kod zvuka, evo jedan link na player kojeg sam radio sa
prijateljem. Izmedju ostalog ima i driver za PC speaker (kad smo vec kod
1-bit enginea).
http://www.iscro.com/stuff/retro/oplay/oplay105.zip
100% pure x86 assembler... trebas imati VESA mod na grafickoj kartici da
bi radio. Isprobano radi pod DOSBox-om, SB 16 emulacijom na 22050Hz, S3
graficka kartica.
Player je nastao kao nusproizvod jer smo se namucili za igru da
napravimo dovoljno brz MOD player pa smo ga onda iskoristili da jos
jedanput pokupimo neku nagradu na izlozbi studentskih radova :)
U igri mozes cuti engine playera u praksi, na mojoj 306-tici na 25MHz je
zauzimao oko 3-5% CPU-a za 4 kanalni MOD file.
http://www.iscro.com/stuff/retro/bluppo/bluppoc.zip
I igra radi bez problema pod DOSBox-om sa istim postavkama.

Igra je zakon!! :-) Pa koliko vremena vam je trebalo da napravite 160
nivoa? Naso sam ju i na Wikipedii:

https://en.wikipedia.org/wiki/Bluppo

Tu je onda bilo i love?

Igra u DOSBox-u radi bez dodatnih podesavanja a za mod player sam morao
za SoundBlaster staviti IRQ 7. BTW, u uputstvima unutar igre se na
jednom mjestu (nakon nekoliko ekrana) umjesto 'it' ispisuje 'it it' :-)

Imas jos source od mod player-a? Tu bi volio vidjeti kako ste mix-ali
sample-ove a da se izbjegne clipping. Ja sam u rutinama za generiranje
visekanalnog zvuka na mikrokontrolerima isprobao nekoliko pristupa ali
niti sa jednim nisam zadovoljan.

MOD file-ove sam isprobao i s OpenMPT tracker-om, neki dan sam ga bas
po prvi put instalirao i za probu poceo raditi 'Sjecam se' od Jure
Stublica pa sam usput developerima postavio nekoliko pitanja:

https://forum.openmpt.org/index.php?topic=5841.0

U roku par sati sam dobio detaljne odgovore na sva postavljena pitanja
i cak je jedan od developera vec u programu nakon mojeg prijedloga
napravio izmjenu koja ce se pojaviti u sljedecoj verziji, a izgleda da
ce prema mojem drugom prijedlogu napraviti i jednu vecu izmjenu u
nacinu koristenja sample-ova.

[Bruno Babic]

Post by Chupo
Igra je zakon!! :-) Pa koliko vremena vam je trebalo da napravite 160

Imali smo jednu level designericu koja je odradila vecinu posla.
Naravno, tek nakon sto smo joj napravili level editor.

Post by Chupo
Tu je onda bilo i love?

Pokupili smo neke nagrade, nesto malo hardvera, nesto malo novca i
nikada nista od prodaje. To je bilo taman vrijeme dolaska Windowsa 95 i
DOS igre vise nisu bile toliko popularne, iako je ova uredno radila i
pod Win 95.

Post by Chupo
Imas jos source od mod player-a? Tu bi volio vidjeti kako ste mix-ali
sample-ove a da se izbjegne clipping. Ja sam u rutinama za generiranje
visekanalnog zvuka na mikrokontrolerima isprobao nekoliko pristupa ali
niti sa jednim nisam zadovoljan.

Negdje bi trebao biti sprzen na nekom CD-u, moram provjeriti. Iako,
sumnjam da ce ti se dati analizirati Assemblerski source da bi skuzio
"sto je pjesnik htio reci" :)

Sto se miksanja tice nema tu puno filozofije - zbroji trenutne
vrijednosti sampleova, podijeli s brojem kanala i salji na output. To je
bilo tipicno ponasanje MOD playera u to vrijeme, nismo radili nikakve
napredne algoritme. Jedina napredna stvar je bila unaprijed izracunata
tabela za brzo dijeljenje/mnozenje kako bismo izbjegli klasicno (sporo)
mnozenje i dijeljenje.

[Bubba]

Bruno Babic's log on stardate Mon 14 Aug 2017 02:32:30p

/snip

Imenjace, ako nije tajna - koliko cesto se u danasnjem poslu dohvacas
nativnog koda (pricamo o x86 ASM-u, jel...)?

[Bruno Babic]

Post by Bubba
Imenjace, ako nije tajna - koliko cesto se u danasnjem poslu dohvacas
nativnog koda (pricamo o x86 ASM-u, jel...)?

Jako rijetko. Ukoliko ne brojimo ovakve (rijetke) situacije na newsima,
posljednji put sam se assemblera dohvatio prije nekih tri godine kada
sam napravio malo rezidentni programcic koji je omogucavao da se
digitalni casopis "Pixel" pokrene bez originalne diskete.

[Chupo]

Post by Bruno Babic
Imali smo jednu level designericu koja je odradila vecinu posla.
Naravno, tek nakon sto smo joj napravili level editor.

U to vrijeme nije bas bilo previse cura koje su se bavile s game
design-om :-)

Post by Bruno Babic
Pokupili smo neke nagrade, nesto malo hardvera, nesto malo novca i
nikada nista od prodaje. To je bilo taman vrijeme dolaska Windowsa 95 i
DOS igre vise nisu bile toliko popularne, iako je ova uredno radila i
pod Win 95.

Steta da niste tu igru napravili ranije.

Post by Bruno Babic
Negdje bi trebao biti sprzen na nekom CD-u, moram provjeriti. Iako,
sumnjam da ce ti se dati analizirati Assemblerski source da bi skuzio
"sto je pjesnik htio reci" :)

U embedded svijetu je assembler jos uvijek svakodnevna pojava :-)

Post by Bruno Babic
Sto se miksanja tice nema tu puno filozofije - zbroji trenutne
vrijednosti sampleova, podijeli s brojem kanala i salji na output. To je
bilo tipicno ponasanje MOD playera u to vrijeme, nismo radili nikakve
napredne algoritme. Jedina napredna stvar je bila unaprijed izracunata
tabela za brzo dijeljenje/mnozenje kako bismo izbjegli klasicno (sporo)
mnozenje i dijeljenje.

Za nekoliko kanala to jos moze raditi i s 8 bit-nim sample-ovima ali
vec i za 4 kanala se tako 256 nivoa dijeljenjem s 4 osmo-bitni sample
degradira na samo 6 bitova a meni je u interrupt rutini ostalo dovoljno
vremena za generiranje mozda i 16 kanala (*) pa bi u tom slucaju
djeljenjem s 16 osmo-bitni sample-ovi imali samo 16 umjesto 256 nivoa
sta bi poprilicno degradiralo zvuk jer bi rezultat bio kao da se
koriste cetvero-bitni sample-ovi sta bi drasticno smanjilo odnos
signal/sum a osim toga bi i amplituda signala u razdobljima kada je
aktivan samo mali broj kanala bila premala.

Za dva kanala to radi odlicno:

// ako nema jumper-a
if(jumper_CHMOD)
// generiranje signala za jedan kanal
OCR2 = (uint8_t)(((((int16_t)pgm_read_byte(waves[ch1.wave]+(phacc

Post by Bruno Babic

8)) - 127)*ch1.amp) >> 7) + 127);

//OCR2 = 127; // za osciloskop
else {
// ako je stavljen jumper
// generiranje signala za 2 kanala
tmp = (uint8_t)(((((int16_t)pgm_read_byte(waves[ch1.wave]+(phacc

Post by Bruno Babic

8)) - 127)*ch1.amp) >> 7) + 127);

tmp2 = pgm_read_byte(waves[ch2.wave]+(phacc2 >> 8));

// ovdje treba napraviti software-ski mixer kanala
OCR2 = (tmp + tmp2)/2;
// kraj generiranja signala za 2 kanala
}

Sample-ovi su osmobit-ni s offset-om 127 pa za amplitudnu ovojnicu na
prvom kanalu sample najprije pretvaram u integer, micem offset da bi
mogo mijenjati amplitudu bez da se poremeti offset, mnozim s amplitudom
(128 = 1), dijelim s 128 (>> 7), vracam offset i na kraju ga ponovo
vracam u uint8_t. phacc je phase accumulator za DDS algoritam sinteze
zvuka i od njega se visi byte koristi kao index u lookup tabelu, zbog
toga je phacc >> 8. OCR2 je registar mikrokontrolera o kojem ovisi duty
cycle PWM signala a to je direktno proporcionalno naponu na izlazu
niskopropusnog filtera.

Taj algoritam za 2 kanala radi odlicno (s tim da je amplituda kada
svira samo jedan kanal duplo manja nego u slucaju kada se koristi samo
jedan kanal) ali za vise kanala bi, zbog ranije napisanoga, zvuk bio
pre vise degradiran.

Postoje neki kvazi-algoritmi za mixanje:

http://www.vttoth.com/CMS/index.php/technical-notes/68

ali to jednotavno nije u redu jer rezultira s distorzijom. Na nekom
forumu koji se bavi s DSP-om pise da je od tog algoritma bolje ako se
sample-ovi jednostavno zbroje pa se, ako je rezultat veci od maximuma,
koristi najveca vrijednost - sta bi rezultiralo rezanjem signala i
unosenjem hrpe visih harmonika ali se mogucnost koristenja takve metode
objasnjava statistiskom analizom gdje se dokazuje da su signali s
raznih kanala relativno rijetko u fazi i da vecinu vremena nakon
zbrajanja ne dolazi do clipping-a.

Moracu pogledati kako je to rijeseno u trakcer-ima koji imaju 128 ili
256 kanala (mislim da neki imaju cak i neogranicen broj kanala).

(*)
Frekvencija interrupt-a mi je 8000000/510 = 15686.27 Hz pa mi za svaki
interrupt ostaje 63.75 us, rutina za jedan kanal s portamento i decay
stage-om od ADSR ovojnice je trosila 12 us a kad sam dodao jos jedan
kanal je vrijeme skocilo na samo 19 us. To su trajanja uz clock od samo
8 MHz a ako stavim vanjski kristal cu uz 16 MHz clock imati jos duplo
vise T-stanja po interrupt-u i uz jos malo optimizacije mislim da ce
raditi barem 12 kanala a mozda i 16. Nakon toga cu vidjeti sta mogu
napraviti s istovremenim processiranjem MIDI input-a, dodavanjem
automatske pratnje i slicno. Vec i s ATmega8 koji kosta 3 kn se moze
napraviti zvuk cija je kvaliteta usporediva sa zvukom sintesajzera s
kraja osamdesetih koji su kostali 1300 - 1500 DM a DSP mi je inace bio
tema diplomskog pa mi je to zanimljivo. Planiram isprobati i sta se
moze napraviti s ARM-om, tu bi se vec mogo napraviti sintesajzer
usporediv s danasnjom consumer klasom klavijatura.

[Bruno Babic]

Post by Chupo

Post by Bruno Babic
Sto se miksanja tice nema tu puno filozofije - zbroji trenutne
vrijednosti sampleova, podijeli s brojem kanala i salji na output. To je

Za nekoliko kanala to jos moze raditi i s 8 bit-nim sample-ovima ali
vec i za 4 kanala se tako 256 nivoa dijeljenjem s 4 osmo-bitni sample
degradira na samo 6 bitova a meni je u interrupt rutini ostalo dovoljno

Nema savrsenog rjesenja za taj problem. Ili ces miksanjem degradirati
kvalitetu samplea, ili ces imati problema sa clippingom i neujednacenom
glasnocom pojedinih kanala.
S obzirom na danasnju brzinu procesora, moguce je da trackeri koriste
neka malo pametnija rjesenja.

Inace, pogledaj ovaj tracker (IMHO, najbolji kojeg sam vidio do sada):
https://www.renoise.com/

Post by Chupo
automatske pratnje i slicno. Vec i s ATmega8 koji kosta 3 kn se moze
napraviti zvuk cija je kvaliteta usporediva sa zvukom sintesajzera s
kraja osamdesetih koji su kostali 1300 - 1500 DM a DSP mi je inace bio

Ja sam davno nabavio Korg M1 jer mi je naletio jeftino, a poslije sam
skuzio da postoji i softverska verzija istog koju sam uredno koristio sa
gorespomenutim Renoiseom. Dakle, vrlo vjerojatno su ovi iz Korga
napravili to sto ti hoces s time da daje dovoljnu kvalitetu za
profesionalnu upotrebu.

[Chupo]

Post by Bruno Babic
Izgleda da su T-comovci digli novi news server, a nisu bili u stanju
napraviti 1-to-1 kopiju pa je puno grupa resetirano. I ja sam imao isti
problem, ali ne cuvam stare poruke pa sam samo napravio refresh svega.

Covjece, sad tek vidim - ako si na t-com-ovom news serveru pogledaj pa
usporedi Xref header-e od postova poslanih prije nego sta se je taj
problem desio i od postova sada kasnije.

Prije je header izgledao ovako:

Xref: news1.t-com.hr hr.sci.elektronika:xxxxxx

a sad izgleda ovako:

Xref: Iskon hr.sci.elektronika:xxxxxx

Sta bi to moglo znaciti?? Iako mi je u news reader-u podesen t-com-ov
news server:

news.t-com.hr

postove od neki dan dobivam preko Iskonovog servera koji ima drugi
article count pa zato news reader-i traze resubscribe (sta uzrokuje
gubitak protected article-a).

Ovdje sam malo prije napisao vise detalja:

http://tinyurl.com/y9tgek25

[Bruno Babic]

Post by Chupo
postove od neki dan dobivam preko Iskonovog servera koji ima drugi
article count pa zato news reader-i traze resubscribe (sta uzrokuje
gubitak protected article-a).

Ocigledno je T-com odustao od toga da ima svoj news server i samo
forwardao DNS na iskonov (T-comov indirektno).