Recent Posts

1

Programming / Re: CPCRetrodev 2021 : Fitzroy Dives Deep

« Last post by Nesu on Today at 01:50 »

Found that stopSound() calls PLAYER_ARKOS_STOP() outside interrupts. PLAYER_ARKOS_STOP() must be called only inside intrerrupts, as it changes the stack pointer for its calculations:

Code: [Select]

_PLY_AKM_STOP::
PLY_AKM_STOP: ld (PLY_AKM_SENDPSGREGISTEREND+1),sp
  (...)
  jp PLY_AKM_SENDPSG

PLY_AKM_SENDPSG: ld sp,#PLY_AKM_TRACK3_DATA_END
 (...)     


2

Hardware related / Looking for a DIN switch

« Last post by ComSoft6128 on Yesterday at 22:07 »

I'm hoping that someone can build me a DIN switch for a Plus.


I'm looking for something about the size of a cigarette packet or a cassette tape box with two female sockets at the rear and at the front a male jack with a 6CM lead from the box to the Plus. The switch can be on the top or front of the box.


£30 + postage seems fair.


If anyone can make this please let me know via this post or PM.

3

Amstrad CPC hardware / Re: USIfAC II:Convert a PC or USB stick to Amstrad HDD,access dsk's,and many more!

« Last post by Mark_wllms on Yesterday at 21:16 »

That completely makes sense. 
I will just have to write a new Mf2 software that writes to sna via USIFAC II!

4

Applications / Re: APL/Z 1.1 on CP/M?

« Last post by m_dr_m on Yesterday at 14:39 »

Thank you for the pointers, much appreciated.

Why the interest?

AP/L is a very terse and powerful language, properties I love!
Context: https://www.cpcwiki.eu/forum/programming/porting-smalltalkjoynimj-on-cpc/

5

Programming / Re: Scrolling and screen tearing

« Last post by ervin on Yesterday at 14:17 »

Oh wow I didn't know that could be done with WinAPE!!!
Thanks again!

6

Games / Re: Ghosts'n Goblins for Amstrad PLUS 128K [PREVIEW]

« Last post by BSC on Yesterday at 13:53 »

All the software handling of a hardware scrolling is still done by a Z80 at the same speed as a CPC. Also, the hard sprites have a non-indexed by a pointer buffer that has to be filled in software. This is certainly more efficient than a soft sprite, but it is not CPU free.

Thanks for your elaborate response, especially the quoted part was not obvious to me (even though it should have), as I said: it looks awesome and I was just wondering. Looking forward to the final release. Keep it up!

7

Programming / Re: Scrolling and screen tearing

« Last post by Axelay on Yesterday at 13:53 »

Thanks Axelay.
That's really useful info.

No problem!  I don't know if you use WinAPE, but if you do, in most cases you can easily check any game you want is using hardware or software buffer by hitting f8 to open the debugger, clicking on the yellow & blue 'find graphics' icon at the bottom, and from the Find Graphics form, select 'Screen' type encoding at the top.   That will automatically select the address of the current display, which will usually have an address of &c000, &8000 or &4000.  You can manually enter the address to see if the game has a another buffer in the format for screen memory, which would usually mean it's hardware double buffered, but not always.  You'd need to verify it's actually changing the CRTC registers to be sure.


If the game is software copying a buffer, it will tend to be from a linear buffer and to see that you would need to change the encoding to 'CPC' and set the width to 64 bytes, or however many bytes wide the play area is and look through memory to find if there's a second version of the screen visible in that format.  But bear in mind that with a software buffer like that, it's not unusual for it to be a bit wider than the play area, so you might need to play around with the width value.

8

Programming / Re: Scrolling and screen tearing

« Last post by roudoudou on Yesterday at 13:18 »

Just wondering... do games like Robocop, Dragon Ninja, Batman the Movie, Shinobi etc use a double buffer?
There reason I ask is that none of them have screen tearing despite scrolling a good-sized screen area.

The memory limitations imposed by a double buffer are severe on 64K machines, and all of these games have a lot of graphics to store during gameplay (even taking multi-load into account). Maybe some sort of compression is used.
OR... is the screen redraw highly optimised, and carefully timed to coincide with vsync?

Dragon Ninja is heavily optimised for speed AND for memory usage, this game is a piece of art 
Most of games using double buffer optimise their memory usage (with some conversion table to flip sprite, change sprites colors, ...)
And i disagree about "lot of graphics" for the games you mentionned. Just take a look at the Truck and the helicopter in Dragon Ninja, they reuse the same tiles. All the levels are very simples

9

Programming / Re: Scrolling and screen tearing

« Last post by ervin on Yesterday at 12:47 »

Thanks Axelay.
That's really useful info.

10

Programming / Re: Scrolling and screen tearing

« Last post by Axelay on Yesterday at 11:52 »

They're hardware double buffered.  But bear in mind, they have also I think in all the cases you mentioned reduced the visible screen to specrtum dimensions, so they're using two 12kb screens, and using the spare or unused 4kb from each of those screen banks for other things as well, so they're using 40kb after screens.


Screen tearing comes from trying to use a software buffer that you copy, usually with LDI strings.  On the spectrum I understand the typical 32x16 character scrolled area can be copied within a frame to avoid tearing with timing, because it's half the number of bytes as the same number of characters on CPC.  You can do the maths to see that tearing is inevitable with that approach on CPC.  32x16 characters is 8192 bytes x5 nops for LDIs, ignoring overhead for the loop comes to around 40000 nops alone.  That's two whole screen refreshes just to copy that buffer to the visible screen.  Software copied buffers didn't just produce tearing, they significantly reduced frame rates.