News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

few noob questions

Started by gorgh, 14:01, 18 August 18

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

gorgh

Hi there,
Since couple of days I'm working of port of the Yoomp for ZX Spectrum (gif in the attachment), and I want to try to port it to Amstrad as well, but there are some questions I have.
1. The unrolled code is circa 40 kb, do you think it's still possible to make a game with such amount of code? (is there a way to read data from the disk? )
2. What do I need to do first to get access to full 64 kb of RAM (usually on Atari there's a ROM switching procedure and setting own interrupts)
3. How much extra time does it take to write to video RAM? Is it comparable to ZX Spectrum and Atari? (15-30% )

gorgh

I'm having a hard time searching through web in order to find some solution of how to switch off system, I would really appreciate some guidenence, is it only a matter of changing adress in $0038 register?

gorgh

ok, I figured it out, one has to change vector in $38 and call 2 routines to switch off upper and lower ROM, and here we go!
BTW its nice that there is such a vast documentation comparing to Game Boy for example, tomorrow I should show some results

Targhan

Quick reply... To switch off the system, all you have to do is... DI! By default, you have access to the full RAM, there should be no need to fiddle with the RAM/ROM configuration.
Targhan/Arkos

Arkos Tracker 2.0.1 now released! - Follow the news on Twitter!
Disark - A cross-platform Z80 disassembler/source converter
FDC Tool 1.1 - Read Amsdos files without the system

Imperial Mahjong
Orion Prime

gorgh

thank you for the answer, I've just started to profile my code for CPC, long night awaits me :)

pelrun

Also there's no performance penalty for accessing 'video ram' specifically. The CPC adds wait-states to every instruction to allow the video hardware to access the RAM, resulting in every instruction being rounded up to a multiple of 4 machine cycles. This makes cycle counting *easier* than for Z80 code on other platforms, but you have to be careful not to blindly use the generic Z80 tables or you'll get the wrong result.

Targhan

As for your other questions:


Quote1. The unrolled code is circa 40 kb, do you think it's still possible to make a game with such amount of code? (is there a way to read data from the disk? )
If you target a CPC 464/664 with only 64kb of memory, 40k is a lot, especially if you want to have a 16kb video screen. But depending on your game, it might be doable. Targeting 128k (which many people, including myself, shamelessly do), you should be fine. Just check your RAM configuration carefully so that your unrolled code can reach the video memory (which can be ONLY on the first 64kb).


Quote2. What do I need to do first to get access to full 64 kb of RAM (usually on Atari there's a ROM switching procedure and setting own interrupts)
Nothing :).

Quote3. How much extra time does it take to write to video RAM? Is it comparable to ZX Spectrum and Atari? (15-30% )
I guess pelrun answered this one. No penalty, just be aware that the video RAM is kind of strangely structured, resulting in an important overhead when displaying pixel-accurate stuff. Your unrolled code might want to address that as much as possible.
Targhan/Arkos

Arkos Tracker 2.0.1 now released! - Follow the news on Twitter!
Disark - A cross-platform Z80 disassembler/source converter
FDC Tool 1.1 - Read Amsdos files without the system

Imperial Mahjong
Orion Prime

andycadley

Quote from: Targhan on 12:11, 19 August 18

No penalty, just be aware that the video RAM is kind of strangely structured, resulting in an important overhead when displaying pixel-accurate stuff.
True. Though not quite as weirdly structured as the Spectrum's video RAM, so I guess he'd be used to it. Changing the screen to be 64-bytes wide instead of 80 (and thus 32 Mode 1 characters) can help somewhat simplify the line calculations since the offsets become powers of 2.

gorgh

thanks a lot for a clues, to be honest it would be hard for me to fit into 64, since unrolled code takes up to 44 kb , but maybe I will use advice and do it for 128 kb, but is it popular extension? How many users use it?
Here's a file and a gif of the current stage
http://parafie.filonet.eu/misc/yoomp.gif
http://parafie.filonet.eu/misc/disk.dsk

Duke

Quote from: gorgh on 21:50, 19 August 18
thanks a lot for a clues, to be honest it would be hard for me to fit into 64, since unrolled code takes up to 44 kb , but maybe I will use advice and do it for 128 kb, but is it popular extension? How many users use it?
44KB should be fine if you don't need the firmware. Just pack it and add a loader to unpack it after it's loaded by the firmware.

Targhan

Quotemaybe I will use advice and do it for 128 kb, but is it popular extension?

Oh, it is not an extension. CPC 464/664 have 64kb, CPC 6128 have 128. MANY people have a CPC6128. I have personnally only developped for 128k "all my life", and never received any threat :). So don't be afraid of using 128k. One can even consider it a standard. The CPC6128 was released after a year or so after the CPC464, which became obsolete (my apologies to the users that will frown upon this comment :)).
Targhan/Arkos

Arkos Tracker 2.0.1 now released! - Follow the news on Twitter!
Disark - A cross-platform Z80 disassembler/source converter
FDC Tool 1.1 - Read Amsdos files without the system

Imperial Mahjong
Orion Prime

Gryzor

That GIF is mesmerising :D


Lovely, and perhaps a good candidate for a Pico8 demake!

gorgh

Duke: but 44 kb is only a plotting code, plus I need 2 kb for tables and the rest of the code, plus at least $7fxx is occupied by hardware registers :)
Targhan: thanks for clarifying, that's a lot better perspective for meh
Gryzor: thanks, I managed to make it also in MODE 0 (screenshot in attachment)

Targhan

QuoteDuke: but 44 kb is only a plotting code, plus I need 2 kb for tables and the rest of the code, plus at least $7fxx is occupied by hardware registers


No! On CPC, except for the video, nothing is mapped to the memory. The #7fxx is only a port, accessed via OUT, so the RAM has nothing to do with it. You still have the full memory for you!
Targhan/Arkos

Arkos Tracker 2.0.1 now released! - Follow the news on Twitter!
Disark - A cross-platform Z80 disassembler/source converter
FDC Tool 1.1 - Read Amsdos files without the system

Imperial Mahjong
Orion Prime

gorgh

Targhan: yes :) LambdaMikel already explained it to me, that just awesome

andycadley

I wouldn't worry about going 128K only, I'd say the vast majority of users probably have access to a 128K machine today (even if only via emulation). It's wasn't that long ago the forum was full of people bemoaning that there weren't enough titles taking advantage of their 256K/512K memory expansions....  :laugh:

gorgh

#16
good to know that, andycadley
I managed to fit 44 kb of unrolled code, and I have still 3 kb spare for future code :)
What I did was using screen memory as a buffer ($c000-$eb00) , where I unroll last part of the code, and then I copied it to location $9500-$bfff
After generating code I overwritten 80% of the code by lookup table neccessary for drawing (it needs 2 kb)
Here it is, working on 64kb but I will aim in 128k since 3 kb is still to little, but at least drawing procedure is in basic ram
(press on image to see animation)
edit: the tunnel is 192 x 192 pixels, it only appears small on the gif

Powered by SMFPacks Menu Editor Mod