Recent posts

#1

Amstrad CPC hardware / Re: Zilog Z84C0020PEG in my CP...

Last post by Prodatron - Today at 16:23

OUT (C),0 is used in all optimized AY routines, so yes, that makes sense with the corrupted sound.

#2

Programming / Re: bits 5 and 3 of F register...

Last post by roudoudou - Today at 15:14

iterating or not with LDI or LDIR, you keep S, Z and C
then you set P when BC will be zeroed
about the non documented behaviour, it's something like this

(((databusValue+A) & 2)<<4) | ((databusValue+A) & FLAG_3_BIT);

#3

Amstrad CPC hardware / Re: Zilog Z84C0020PEG in my CP...

Last post by roudoudou - Today at 14:55

most of problems are due to (i guess) OUT (C),0 undocumented opcode which was fixed (or reassigned) in later versions

#4

Amstrad CPC hardware / Re: Zilog Z84C0020PEG in my CP...

Last post by Prodatron - Today at 13:04

Thanks for reporting!
Very interesting, I would like to hear about more testings.
I wonder if the issues with BG-stuff are undocumented instructions or timing.
(btw I really like your Basic hacks!)

#5

Programming / Re: bits 5 and 3 of F register...

Last post by Fran123 - Today at 12:57

Is there any reason why you should know about these undocumented bits in the F-register beside to develop a 100% correct Z80 emulator?
I never understood why this was necessary to know. Does it have any advantages for making code better/faster/shorter? Does anyone have an example for this? Or is this just for fun (which includes detecting, if a Z80 emu is cool or not).

I trying to emulate the z80, I'm not planning to make another RVM either

#6

Programming / Re: triple buffering

Last post by ervin - Today at 10:44

Sounds like a good scheme.
Thanks!

#7

A

General Discussion - Introductions / Re: Interview with Dave Rogers

Last post by Anthony Flack - Today at 10:13

While most people remember his music, for me it will always be The Scout Steps Out and especially Radzone. I love that game. 

#8

A

Programming / Re: triple buffering

Last post by Anthony Flack - Today at 09:58

If you want to do something along these lines, the memory arrangement I used:

Main code goes in bank 0.

Front/back buffers are in bank 2 and 3 at &8000 and &c000.

Clean buffer, compiled sprites, and any other code all swap in to bank 1 at &4000, so that you can copy from any of these banks into either screen buffer. 

#9

C

Games / Re: CPC Formula 1 [WIP]

Last post by cwpab - Today at 09:57

As a feedback, I'd say that it looks like you can't see s**t with the current camera and speed. Maybe the camera could be moved up a little or the speed reduced?

EDIT: I think it's the peculiar format of the video with margins. I suspect the movement would look normal in a normal video.

#10

L

Games / Re: CPC Formula 1 [WIP]

Last post by luckpro - Today at 09:40

I invented a steering wheel for the cpc.  It would be connected through the expansion port.  I have not implemented it but the scheme is very simple.  It could be turned with different degrees and the steering wheel and brake would also have different degrees.

It might be interesting to add support for it. even for the mouse interface. Thank you.

Looks great, are there any technical details how this fake mode 7 works in this game?
Line doubling? 32 char wide screen for optimal maths? Byte addressing, not nybble.

Fixed sky area (6 chars), double buffer game area (13 chars), fixed car view area (6 chars), 32 width chars to optimize memory space for double buffer (not strictly for the maths) <---- SyX programmed me the interrupt function to use this configuration. Thanks SyX I owe you a beer .

The game area have 8 chars to draw mode 7 (calc 32 lines and i duplicate it to 64 lines) and 2 chars to background image.

Right now, the game runs at an average of 8/10 frames/sec (if you have to draw walls very close the framerate can drop quite a bit ). But I still have a lot to implement and it may change a little.

To make fake mode 7 (Patent pending )  i have a table with precalculated data of the view (xy displacement of each visible line at that angle) and the game moves the player's position and calculates what color is drawn at that position in a loop.

To make these calculations faster, the game uses a part of the tile map and transforms it into a little bitmap in runtime (1 track pixel, 1 byte) so as not to need to process the nibble or tile information in the loop.

Walls info is in the same tile pixel info. While the loop check the pixel of the floor it can detect the wall and save it to draw at the end. The wall drawing scale wall info pixels in runtime.

If you want more specific information, ask me whatever you want. Thank you.

That is mighty impressive!

I would love to see the actual car you are driving to give it that FZero vibe.
I was also thinking how nice it would be to not make it an F1 game, but a PowerDrift type of game instead so that it would have hills, dips and jumps. I'm guessing that a lot more memory would need to be freed up, so it would probably need to be a mode 1 game?

Thank you sigh, unfortunately the engine is designed so that the ground is flat. It is drawn horizontally to make it faster. To do what you mention i would have to draw vertically and do more calculations, i guess it couldn't be done that quickly (or at least I don't know how to do it). 

The graphics mode doesn't matter too much in memory for this game.