P.O.C. Chuckie Egg on Taito L System

ben76

ben76

Hunts Spies
Feedback
7 (100%)
Credits
1,136CR
/me goes and finds his flipull pcb.....

Nice work
smiley20.gif


- Ben
 
C

cmonkey

Active member
vacBacker
Feedback
4 (100%)
Credits
1,658CR
Mitchell Gant said:
How the heck do you get that much done so quickly!!!
smiley3.gif


You got a time dilation machine hidden somewhere???
smiley36.gif


But keep it up however you're doing it.
Click to expand...

Maybe I was being a little on the 'conservative' side when I said a couple of hours work as I already have my sprite engine almost finished on the L System, and that took many hours to code. So for this it was simply a case of transcoding the sprites/tiles from the Spectrum version of the game and plugging them in to my sprite engine. Also, only left/right is implemented in the engine at the moment, the ladders are merely to show what can be....
 
C

cmonkey

Active member
vacBacker
Feedback
4 (100%)
Credits
1,658CR
backflipper said:
Nice!
What made you choose this hardware?
Click to expand...

Thanks for the nice comments everyone.
smiley1.gif


I chose the L System because it packs a lot of power in a very small footprint. Due to the fact that it came along late in the life of 8-bit boards, when 16-bit boards were prevalent, Taito knew that they had to produce something a little bit special to try and get the operators to buy the games. That special something was the TC0090LVC integrated CPU/system controller. This single chip is responsible for everything in the game (core game logic/sound/text/tile/sprite generation). I'm not aware of any other board that does so much in a single chip. In it's simplest form, the L System is pretty much a single chip board set with a bit of rom and ram and an address decoder.

I also like the idea that tile and sprite data exists, and can be happily intermingled, within the same roms. Ordinarily you'd have separate roms for tiles and sprites as the data within them is usually retrieved by independent circuits on the board. The format of the tiles/sprites is also identical (with the exception that tiles are 8x8 and sprites are 16x16) so this meant that I only needed to write a single tool to convert 4-bit 16x16 pixel BMPs to the tile/sprite format used by the L System. You can display tiles as sprites and sprites as tiles, due to the flexibility of the TC0090LVC.

Using Plotting as my target board, there are 2 x 27512 roms for tiles/sprites. The 4 bitplanes for each tile/sprite are split across the 2 roms (bitplanes 0 and 1 in the first rom and bitplanes 2 and 3 in the second rom). A single tile needs 32 bytes (16 in each rom) and a single sprite needs 128 bytes (64 in each rom). This means you can have up to 4096 tiles or 1024 sprites, or any combination of those, all within 2 roms. You're not restricted where you put the tile/sprite data within the roms either, you can put it anywhere and access it via a page number (16 pages of tiles or 4 pages of sprites, 256 tiles/sprites per page). It's a really flexible way of doing tile/sprite data IMHO and means I only have to reprogram a couple of roms, even if I change every single tile and sprite in my code.

I just wish it had pixel level access to the frame buffer, that's the only thing it's lacking in my eyes. But that's a small price to pay for all the benefits that the system offers otherwise.

Plus the fact that the TC0090LVC has a Z80 core, which ties in well with my Spectrum roots.

I guess I see the L System as a "Super Spectrum" where everything that the Spectrum had the L System goes 1 better :-

Spectrum L System

Frame buffer size 256x192 320x224

Sprites software 120 (hardware with x/y flip and priority)

Tile layers 1 (software, same layer as sprites) 2 (hardware scrolling)

Text layer 1 (same layer as sprites/tiles) 1 (independent, non-scrolling)

Colours 16 fixed 16 palettes of 16 colours (4-bits per RGB giving 4096 colours in total)

Sound beeper YM2203 FM sound chip

Colour clash lots none ;-)
 
You must log in or register to reply here.
Top