Strony

2012-01-02

$7dc

There was not much progress in 2011. I've been lately very busy with my work projects ( this and this one). But at least i've prepared a TO-DO list for 2012 ;) :

1. VEGA ( Olympia, 1982 )

I have recently got Vega PCB. Special thanks to Mark Frisbee for help.


Unfortunately board has few faults ( no sound, gfx glitches ) and inverted colors (like early Nintendo boards). Theres a couple solutions for the latter problem. I have decided to mod the pcb a bit and invert the digital signals before the DAC (made of resistors). Here's a video from attract mode:



So, next step is to emulate the game :)

2. TIME ATTACKER ( Shonan, 1980 )

Currently i'm making schematics of video section. It's similar to classic Pong discrete logic, but a bit more complicated (game has Z80 cpu). TA is a breakout clone, with special add-ons like oil zones and moving enemies ( btw : background color - blue or black - is selectable with a jumper on board ):



3. WHEELS & FIRE ( TCH, 199? )

Not much about this one. I'm in the middle of MAME driver rewrite process (based on game sources i got from the author).

2011-05-23

Let's play tennis!

Here's few pics from Reality Tennis by TCH (pcb recently acquired by Dumping Union ). Game runs on blitter-based hardware, similar to Wheels&Fire, but more simple. Current emulation status: game playable with few gfx glitches and without sound.

More great news - i have recently contacted Antonio 'Peluko' Carrillo - programmer and game designer of both Reality Tennis and Wheels & Fire. He has provided tons of usefull info about the w&f hardware and the game code. The first, big improvement is (a bit buggy) sound emulation.
I'm going to rewrite the whole video hw emulation of w&f, and disable all hacks & precalculated zoom tables. Quite challenging, but worth the effort.

Ok. Back to tennis:






2011-01-16

Seibooooo

After a (12 months) break updated my other blog.

2010-12-31

If i could turn back time....

I fixed a couple of video/sound issues in Chouji Meikyuu Legion emulation:
- added SFX,
- fixed video priorities (no more garbage gfx over the playfield),
- simulated protection in"legion" set, so the functionality is now close to the other ("legiono" - possibly a bootleg) set,

Legion was _almost_ playable before. It's still not perfect (broken test mode, missing various text strings here and there ) but imo more enjoyable.

Game has really unique (as for 80s) feature - 'time warp' bombs. How it works? Try it yourself ;)

Here's a couple of shots from the game:

2010-09-29

Busy.. busy.. busy ...

Something VERY special!
Purchased by Dumping Union. Donators:

Cananas, Mr. Do, S. Brown, J. Bijl,ranger_lennier, F. Xerri, Gor, Kevin Eshbach, Smitdogg, Guru, Tormod



Another game from '80s - 'Super Wing' (thx wulfman) .
Preliminary screenshots:


Also this. Bought it few weeks ago:


It's set of boards from THIS machine.

Interesting mix of hardware ( adp.c + artmagic.c ):

- JAMMA pcb with 68k + tms34010 + oki(sound) "Made In Belgium". All eproms/pals has A&Mxxxxx stickers = art&magic
- adp/merkur cpu board - 68k + eproms + nvrams, eproms labelled "shooting star"
- adp/merkur i/o + sound board - 68681 + ym2149
- "gewehrcontroller" pcb (gun controller) with 80c31 ram and rom
- few smaller pcbs with triacs, resistors and other analog components
Not emulated yet.. no screenshots ( just black screen .. due to protection)

2010-06-23

Wheels & Fire

After looong break i'm looking again at Wheels & Fire from TCH.
Game is running on custom, blitter based hardware (sprites + framebuffer layer with linescroll feature, and sprite-to-framebuffer rendering mode ).
I have made a lot of changes/improvements lately, but there's still a lot to do:
- proper image scaling - quite weird (close to hardware, i think) way to draw scaled images. for more details pls scroll down to the end of this post.
- framebuffer (various problems)
- sound - not emulated yet (2nd 68k + samples)


Here's few pics from the game:


W&F video hardware supports image scaling. For each image(sprite) to draw, there's a couple of parameters sent to the blitter:
- screen cooridnates of image rectangle ( top left ad bottom right corners) _after_ scale transform applied,
- source image cooridnates (only the upper-left corner, no info about the source dimensions),
- two sets (for x and y scale) of magic parameters : data1 (5 bit), data2 (5 bit), four flags ( double/half scale , zero/nonzero params (maybe they are just the MSB of the data1/data2))
Magic ;) parameters are packed into 5 bytes. They are essential to udnerestand how the hw works and how the scaling is done. So far it's just pure magic ;) Params are copied from a lookup table addressed by the scale factor (0-400%):

X Scale Table:
7 6 543210
---ABCDE
---FGHIJ
--------
---K-L-M
-------N

Y Scale Table:
7 6 543210
-A------
DE------
BC-FGHIJ
--K-L-M-
------N-


BITS ABCDE = DATA1 (0-31)
BITS FGHIJ = DATA2 (0-31)
BIT K - ( scale > 200% ) ? 1 : 0
BIT L - ( DATA2 != 0) ? 1 : 0
BIT M - ( DATA1 != 0) ? 1 : 0
BIT N - ( scale < 50% ) ? 1 : 0


Both (x and y) tables contians exactly the same data, just shuffled arround to easielly pack (by OR-ing) into 5 bytes and send to blitter. For now i'm uisng lookup table to determine the scale factor (based on the above params). Works pretty well, but the goal is to underestand how the data is interpreted by video hw and emulate it properly.


RED = data1 (0-31), WHITE = data2 (0-31)
Ranges 25-50% and 50-100% (as well as 100-200% and 200-400%) contains very similiar data, and the first one has special ("half") bitflag set (same for 200-400% - there's another bitflag set("double")). Probably for change the video hw (fpga based) pixel counter/clock.

Both data1 and data2 are mysterious for now. There's few ideas about them:
- fixed point 5.5 (src pixel delta/step?)
- pair of step + oveflow for src pixel "counter"
- floating point num (5 bit mantissa, 5 bit exponent)

A couple of examples ( scale factor - data1 - data2 - bit M - bit L) :


Any ideas ?

2010-03-12

It's full of stars! - Vega, part3

I was wrong - there's no "type 3" sprite. It's just a background layer made of 16 different 32x32 pixel tiles. Tilemap (128x8 cells (4096x256 pixels), animated (flashing stars and texts) ) is hardcoded inside one of eproms used as a lookup. Here's a screenshot from game - shows only the most boring part of bg - stars: Game is not playable (yet) so i can't see other levels / backgrounds. These images are ripped directly from the tilemap (wrong colros, as usually ;) : There's also an interesting hw feature - background can be stretched horizontally (in fact - vertically (div scnaline clock by 2), because screen is rotated by 90 deg). It's probably used (only?) to display the planet surface:

2010-03-10

25 light-years away from home - Vega, part 2

The good news - i have got scans of vega schematics (big thanks to Kold666)
The bad news - hardware is quite old (early 80s .. possibly 1982 or 1983) (read: unique and complicated) and schems are buggy as hell.

The biggest problem so far - no reference images/screenshots/flyer pics. Nothing. I have no f***ing idea about the real game.

So any info will be greatly appreciated.

Schems are as mysterious as the pcb pics i got - no info about the major ICs.
But looking at pinout i have identifed all of them as:

- i8035 (mcu)
- AY 3-8910 (sound)
- PPI 8255 (i/o)
- INS 8154 (i/o + ram)
- DP 8350 (crt controller)

AY is used only for generating sfx. Afaik there's no music. Sound chip is connected in unusual way - AY data lines are tied to address bus and AY address/data write selection is connected to mcu R/W line. So, writing any data to address NNN within range mapped to AY - results in setting AY address register to value NNN. Reading from address MMM store MMM in AY data register. Weird, isn't ?

Graphics hardware consist of four different "blocks":

- text layer - 1bpp fonts with hardcoded (PROM) color for each character. Bullets and some type of enemies are made of characters on text layer.
- four "type1" sprites - simple format, 32x32 pixels, horizontal flip, direct color (1r1g1b + extra unknown bit). Used mainly for enemies (spaseships)
- single "type2" sprite , used for player's ship/explosion only- 32x64 object made of 32x4 slices.
- single (?) "type3" sprite - not emulated yet. Quite big (possibly 64x64) obejcts (planets, asteroids) with special 2kb lookup table.

So far, the most complicated to emulate was the type 2 player sprite. It's auto-animated (based on vblank counter). There's also a 256x4 PROM used as a lookup table , connected in a bit weird way :


Here's some (test/temporary) formula i'm using to draw the sprite:

And now few fresh screenshots. Sprite positions (type1 and type2 (last pic)) and colors may be wrong:


2010-02-16

Vega

Tym razem na warsztacie VEGA (włoskiej produkcji - Olympia). Początki są obiecujące - na razie działa tylko Text Layer (prawdopodobnie na kontrolerze crt DP8350). Całością steruje CPU Intel 8035. Reszta hardware nieznana (na jednym z niewielu dostępnych zdjęć PCB większość istotnych IC ma starte oznaczenia ): Kilka wstępnych screenów:

2010-02-12

Więcej kulek ...

Pachifever jest już grywalne. Kilka informacji o hardware: - CPU - TMS9995 - VIDEO - TMS9928 - AUDIO - SN76496 + MSM5205 (nie mam potwierdzenia co do powyższych informacji (oprócz MSM) więc to tylko przypuszczenia). Gra korzysta z tradycyjnego (mechanicznego) kontrolera Pachinko i trochę kłopotu sprawiło podpięcie sterowania. Brakujący ROM zawiera - prawdopodobnie - część efektów dźwiękowych oraz dane potrzebne do ich odtwarzania. Skutkiem tego jest - niestety - brak sfx :( Kilka nowych screenów:

2010-02-08

Fever

Postępy w emulacji Pachinko Fever (a może Pachifever lub Fever 777?). Ciekawy hardware na bazie TMS9900 (jeden z pierwszych 16 bitowych CPU). Niestety, to prawdopodobnie zły dump - dwa obrazy ROM-ów są identyczne :(

2009-12-02

La Girl...

Tym razem dump z zasobów Guru - koreańska przeróbka Play Girls (kopia Taito L-System hardware zrobiona na trzech układach TPC1020 (FPGA Texasa)) . Zmieniono tytuł i wsadzono nową grafikę tła - soft anime (dlaczego nie tentacles z 'La Blue Girl' ?). Grywalność bez zmian ...

2009-12-01

Kolejna gra ze SNESa w wersji arcade.

Pojawił się nowy dump (sygnowany przez Volkera Hann & Team Europe) gry działającej na pirackim hardware konsoli Super Nintendo. Prawdopodobnie to jedna z pierwszych gier przerobionych w ten sposób - brak skomplikowanych zabezpieczeń i wymyślnego szyfrowania. Twórcy hardware przemieszali jedynie linie szyny danych ROM - "bruteforce" (8! permutacji do przetestowania ) i po krzyku. Z ciekawostek - tekst (copyright) znajdujący się na początku ROMu został lekko zmieniony - poniżej wersja ocenzurowana. Gra o której piszę to Iron znana na platformie SNES jako Iron Commando. Zmieniono screen tytułowy, dołożono obsługę coin slotów oraz DSW. I.. to tyle :)