System timed cheat tool - Taito L System tech demo

[cmonkey]

It's really not though, is it.

When you watch some of the amazing Amiga demos like Jesus on E's or State of the Art or even Speccy demos like the Shock Megademo and then you watch this crap you realise just how crap my crap attempt at demo writing really is.

 

[Hurray Banana]

It's really not though, is it.

When you watch some of the amazing Amiga demos like Jesus on E's or State of the Art or even Speccy demos like the Shock Megademo and then you watch this crap you realise just how crap my crap attempt at demo writing really is.

Ade don't forget you're limited here by not having access to the frame buffer directly. You're limited to sprites and tiles mate. Which means you can only do jiggery pokery by having things like lots of pixel shifted offsite tiles (well that's what I'm gonna do for my first experiments with the pacman hardware, thanks to you're explanations).

 

[cmonkey]

Yeah, I guess so Eric, having pixel level access to the frame buffer makes a massive difference to what you can achieve visually. And also those amazing Amiga/ST/Speccy/C64 demos probably had a team of quite a few people working on them, I did my demo all on my own so I guess that counts for something.

I think that coders are always very critical of their own work and always believe they could have done better given more time.

 

[Hurray Banana]

Hyper critical myself, but that's because always writing code with a tenth of the time available and having to hack stuff in rather than start from scratch is the norm for me. So lot's to be critical about

Just started messing with pacman, god my assembler is so rusty I need a welding torch and angle grinder just to get me going

.

This in the long term is good for my soul, never happier than when I was doing assem. Thanks for pushing mate

 

[guddler]

Ahh, this reminds me of a question I was going to ask!! And I can see now what the answer is regarding this hardware however, more generally...

I was going through my Amiga dev directory last night and I found a small bit of code I was playing around with last year. That code needs looking at as despite using the (a?) frame buffer and switching between the two active buffers just drawing a very simple box was leaving a very noticeable trail.

This led me to the question that if coding for arcade hardware do you need to do the same and have more than one buffer, swapping them each time you complete a screen full of drawing? Or does it not work like that?

 

[cmonkey]

I studied the architecture of a few different boards in my search for a viable target to port CE2 to and of those none of them had a double buffered screen. That's not to say that there aren't any boards out there which do though, it's just that I haven't come across one yet.

A quick scan though the MAME source, searching for the words 'double buffer', shows that there are maybe a few that support a full blown double buffered frame buffer. Quite a few more boards seem to support double buffered sprite ram (2 banks of sprite ram where you can flick between them via setting or clearing a bit in a hardware register).

My guess is that most raster based boards probably work in a similar way to the L System in that when you place a sprite on screen (and/or move that sprite around) you aren't writing directly to the screen when you do so. Instead you're usually writing sprite config data like x-pos/y-pos/palette/sprite number/x-flip/y-flip/x-scale/y-scale/etc to sprite ram and then when the vblank occurs the hardware reads the sprite ram and updates the contents of the screen accordingly, during the flyback. That avoids any flickering of sprites. All the boards I've studied work in this way.

Similar things probably happen with tilemap scrolling to prevent flicker. In the case of the L System the screen is momentarily turned off (for a few microseconds) when the tilemaps are scrolled.

I guess this does away with the need for a double buffered screen.

That's my take on it anyway, but then what do I know!

I've no idea how vector based games work in this respect, you and Mitchell Gant know those way better than me!

 

[Mitchell Gant]

My guess is that most raster based boards probably work in a similar way to the L System in that when you place a sprite on screen (and/or move that sprite around) you aren't writing directly to the screen when you do so. Instead you're usually writing sprite config data like x-pos/y-pos/palette/sprite number/x-flip/y-flip/x-scale/y-scale/etc to sprite ram and then when the vblank occurs the hardware reads the sprite ram and updates the contents of the screen accordingly, during the flyback. That avoids any flickering of sprites. All the boards I've studied work in this way.

Similar things probably happen with tilemap scrolling to prevent flicker. In the case of the L System the screen is momentarily turned off (for a few microseconds) when the tilemaps are scrolled.

I guess this does away with the need for a double buffered screen.

That's my take on it anyway, but then what do I know!

That would be my take on it too. You absolutely must be synchronised to the vertical screen refresh, otherwise flicker, tearing and jerky movement appear very quickly.

I've looked at Tiger Heli hardware and that only allows CPU access to the tilemap memory during the vertical blank period, so only a couple of hundred microseconds to do your stuff. This would not be apparent from looking at MAME either, as it doesn't accurately reproduce how the hardware works. Other game hardware may be different.

It doesn't mean that you have to do ALL your updates in that vertical blank period though, just be synchronised to it. I believe that Williams Defender hardware had a 4mS interrupt driven from vertical blank, so you get 4 interrupts per screen refresh. So now your software can know which part of the screen is being drawn to the screen and make sure it is updating the other areas.

The key to smoother flicker free graphics is this type of synchronised memory access, and I think that is a very important thing to remember when trying to program these boards.

I've no idea how vector based games work in this respect, you and Mitchell Gant know those way better than me!

With vector games there is no equivalent vertical flyback/VBLANK/VBI period. You simply tell the vector generator to start, it takes however long it takes to draw every vector then halts. You have to poll the HALT flag in software then tell it to go again. More vectors mean longer to draw, so more potential for flicker. Empire Strikes Back AT-AT level shows some flicker for example.

When I did that Inspector Vector of UKVAC screen the redraw rate was something like 180Hz as there was so little to draw. It looked ace at that rate on a real monitor!

You do still have memory writing sync problems though, your software can't be changing vector instructions that the hardware is currently reading. From what I have seen in Atari vector games they use a simple double buffer type technique by setting the first vector instruction as a jump to one of two vector memory chunks. While the vector generator is drawing from chunk 1, let's say that's address block 0x4100-0x43FF, then your software is writing/updating the instructions in chunk 2, say 0x4400-0x47FF.

Also I'd say it's not a crap demo either. It's an important milestone as it's the **first** demo on arcade hardware. I doubt the first Amiga demos were that good either, but they evolved as the limits of the hardware were tested. It's all a limit of time that can be spent hacking at it, and as a hobby that's the difficult part to find!

 

[guddler]

OK, I'm a little confused now.

Not on the vector stuff. Neil beat me to it on that, and with more detail. I didn't know about Atari's technique for defining the two areas for instance so thats an interesting detail. I was simply going to say you issue draw commands until you either are done or run out of vector memory. If it flickers, then you're taking too long as the first vectors are fading before you get to the last. Optimise what you're doing or accept the flicker (I do wonder if you could implement some kind of fade on the intensity? I don't think so though as while it would solve the problem of the earlier vectors fading, they'd start off too bright).

Anyway so I get that the majority of the hardware doesn't use frame buffers and that's basically what I expected. I guess being dedicated hardware it's easier to provide dedicated display sections. Actually, thinking as I type, maybe I'm not so confused. Lets say that your board expects a bunch of data representing tiles or sprites, or whatever to be in a specific area of memory, much like the vector RAM on Atari vector. Would you then define an area in program memory where you might have 1 or 2 of these such work areas and then during an interrupt that co-incides with vblank you copy that data into the required video ram area? I guess only bothering with such a technique when your hitting the problem that you can't get it all done in vblank?

OK, what I've written may not make as much sense as what I've thought, but I think I've got it

 

[Hurray Banana]

I think I understand what you mean martin, all you'd have to do quick in the vblank was blitting the current buffered tile map to the actual tilemap addresses and flipping the buffer address.

Which means you don't have to get your code running at 60hz, if you're doing something complicated.

 

[cmonkey]

Thanks for the info Neil, it was very informative.

Also I'd say it's not a crap demo either. It's an important milestone as it's the **first** demo on arcade hardware.

As much I'd love to be credited with the first arcade homebrew demo I'm afraid that's not the case. Homebrew on Neo Geo hardware has been going for quite a while now (it was seeing the Neo Geo 3D! demo that was one of the drivers for me to attempt a similar thing on a different architecture).

https://wiki.neogeodev.org/index.php?title=Homebrew_software&t=20141113035239

 

[guddler]

I think I understand what you mean martin, all you'd have to do quick in the vblank was blitting the current buffered tile map to the actual tilemap addresses and flipping the buffer address.

Which means you don't have to get your code running at 60hz, if you're doing something complicated.

Yep, I didn't explain myself overly well but that's exactly what I meant!

 

[guddler]

PS: I know it's arcade hardware, but NeoGeo doesn't feel like dedicated hardware to me. It's already playing many different games. But then I suppose a lot of the hardware systems are...

 

[cmonkey]

Anyway so I get that the majority of the hardware doesn't use frame buffers and that's basically what I expected. I guess being dedicated hardware it's easier to provide dedicated display sections. Actually, thinking as I type, maybe I'm not so confused. Lets say that your board expects a bunch of data representing tiles or sprites, or whatever to be in a specific area of memory, much like the vector RAM on Atari vector. Would you then define an area in program memory where you might have 1 or 2 of these such work areas and then during an interrupt that co-incides with vblank you copy that data into the required video ram area? I guess only bothering with such a technique when your hitting the problem that you can't get it all done in vblank?

Most raster based games are made up of layers, you usually get a text layer, at least one tile layer and a sprite layer. You usually write values directly to the text layer and tile layer(s) but NOT to the sprite layer. This means you don't need to allocate a section of main cpu ram to buffer text/tile data as you write your data directly to text/tile ram.

For games which support scrolling tile layer(s) then the layer is ALWAYS bigger than the visible screen area. Then when you want to scroll the layer left/right/up/down you write your new data to the area of tile ram that is outside the visible screen area and simply scroll the entire layer. This is the concept by which all side-scrolling platform games and horizontal/vertical scrolling shooters work. In the case of shooters where the tile layers(s) is/are always scrolling then the code is constantly feeding the off-screen tile ram with new data and scrolling it into view as you progress through the game. In the case of scrolling platformers then the game is constantly polling the stick, if you let go and the character comes to a halt then there's nothing to do. As soon as you push u/d/l/r then the code starts filling in the appropriate off-screen tile ram for the direction it will scroll in, based on the direction you pushed. The actual scrolling of the tile layer(s) will always be done at vblank time and it will be a very efficient, highly optimised part of the hardware that will do it.

Text layers don't usually scroll.

One of the joys of the MAME debugger is that it tells you the beamx and beamy position of the raster so you know how much more code you can squeeze in to a frame before it hits the bottom of the screen. The most computationally intense part of the demo is when the 72 sprites are moved simultaneously from the bottom of the screen to spell the word CMONKEY in big letters. When those sprites first set off and all 72 are moving at once the raster is getting to a beamy of approx. line 195. For every frame of this sprite positioning routine the CPU is calculating the in-between points from start point to end point for each of the 72 sprites, this is pretty intensive, as you can imagine. The vblank starts at line 240, so I still had a little bit of frame processing time available to me to do other things, but not much. I was very anal about getting all frame processing, for every single of the frame of the demo, within a single frame so that the entire demo ran at 60fps.

 

[cmonkey]

PS: I know it's arcade hardware, but NeoGeo doesn't feel like dedicated hardware to me. It's already playing many different games. But then I suppose a lot of the hardware systems are...

Be careful, you'll have the Neo Geo lovers on your back for saying things like that!!

 

[cmonkey]

We just have to get heads round the audio.

Coming soon, to an L System near you....

 

[Baggers69]

Nice one cmonkey I may need to get hold of a board, is there an emulator that allows you to run modified rom set for it? looks like fun!

 

[cmonkey]

Wow! I'm truly honoured to receive a comment on my crap coding efforts from the legendary Mr Bagley! Thanks!

You can run modified rom sets in MAME, that's how I did all the dev work for this demo.

I'm really hoping you stick around in the homebrew section and chip in with some of your extensive game dev knowledge. It'd be awesome to have someone of your calibre offering hints and tips to us wannabee's.

btw love what you've done recently with Dragon's Lair on the ZX81, a real piece of genius there. Well done!

 

[Baggers69]

No worries cmonkey it wasn't a crap coding effort, you have your code running on arcade hardware! Give yourself a pat on the back young man! top job! there's not many can say they have done it!
Another of the reasons I had to do PacManicMinerMan, because I wanted to, there are a lot of coders in the games industry, who have been in it as long as I have and have never written anything that runs on arcade hardware, I'm probably the only one I know personally that has, so you've done something more than they have too!

Cheers for Dragon's Lair yeah I'm well chuffed with how it's turning out considering the limitations lol

 

[Sokurah]

Awesome demo (yes, I know that I'm a bit late to the party

).

I just signed up yesterday mainly to get access to this homebrew part of the forum as I've wanted to write a game for arcade hardware. It's been a "dream" for probably over 10 years. Nothing has come of it yet though, but this forum seems like a really good place to seek information on homebrewing for Z80 arcade hardware, so hopefully this will help me get started.

I've looked through all the games in MAME dozens and dozens of times to find the most suitable hardware to code for and finally I arrived at the conclusion that Side Arms was the best option. It has a good resolution, lots of sprites, lots of colours and scrolling - and it's based around a Z80 processor.

So I spent a lot of time disassembling the game back then, to figure out how the hardware works, but since it's many years ago I never got anywhere as I simply just didn't have the necessary skills back then. But it's a great game and now I have the arcade board so the time wasn't completely wasted.

But now I see that the Taito L System seems even better. Much more compact and apparently very simple yet packing a great punch. Awesome. I'd love to make a game for it...someday.

I've made 3 games for the ZX Spectrum and is working on a new one right now, so I'm somewhat experienced coding in Z80 (I've also made many games for Windows and Mac - you can check them out using the link in my signature).

I hope I can convince cmonkey to part with his code-skeleton for this board so I can get into experimenting with some code instead of having to invent the wheel again.

 

[Alpha1]

Welcome the forum!