News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

create good cpr for gx4000

Started by dub, 08:46, 23 September 16

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

andycadley

Quote from: roudoudou on 22:17, 25 January 23when booting CPR, with any number of ROM, the ROM 0 is mapped both LOW and HIGH :) (even with a 16K cartridge)
The docs disagree:

"At reset, page 0 is visible in the range &0000-&3fff. DFxx is reset to 0 at this time (logical page is set to 0). This means on GX4000 page 1 will be visible at &c000-&ffff. On the Plus, it depends on /EXP. If /EXP is low, page 1 will be visible at &c000-&ffff, otherwise page 3 will be visible and CPM will be auto booted."

siudym

I made a simple demo of the game, but still a lot of work because I still don't fully understand some things in CPC+.
I have no idea if it works on real hardware, on WinAPE and Arnold it seems OK..

roudoudou

this cannot RUN, you enable interrupt with stack in #8000 and Asic enabled, so the return address can't be written in Asic #7FFE
an interrupt will occur soon, return to zero, infinite loop
sure Winape is ok with that?
put stack in #C000 to be safe, this will push first values in #BFFE, #BFFC, ...
My pronouns are RASM and ACE

andycadley

It looks like it runs in WinAPE, though not RetroVirtualMachine. On a real machine the ASIC registers would prevent write-through or reading of RAM locations even where there aren't registers, so I'd call that a WinAPE bug. Easily fixed by moving the stack to a "safe" location where you aren't going to be paging the ROM or ASIC in and out, #C000 is a good call (the Z80 decrements the stack pointer before PUSHing a value so it won't matter that #C000 itself might be under a ROM).

From what I can see in WinAPE though, you've certainly come along and I'm looking forward to seeing where you go with it. Keep asking questions if there is anything you don't understand. I'm thinking of trying to make some "how to write a game for the GX4000" tutorials and so seeing the bits that don't make sense to someone starting out is helpful in and of itself.

siudym

Right. I changed it to $C000, forgot about it :/ I try not to use or change 4000-7FFF at all and leave "unswitchable" only for ASIC, and use 8000-BFFF as typical user RAM (I understand that in GX4000 it is safe, free space and NOTHING is using anything there?)

A tutorial like this would be great. Please believe me, but recently I started writing something for the first time for 3 systems - C64, Atari 8Bit and Amstrad. In the case of the C64/A8, I managed to do a lot in a short time and everything was very clear and transparent, while the Amstrad, I don't know why, but it is "not clear" for a beginner.

For now, I'm finishing my adventure with Amstrad, but I'm still glad that I got to know this interesting architecture a bit.

andycadley

Yeah 8000-BFFF is free RAM, unless you deliberately map the lower ROM there (and you've probably no reason too).

I think one of the "interesting" things about the GX is that the hardware was originally designed to be a home computer and then the console features are kind of bolted on in a way that minimises backwards compatibility issues. The result is a system that doesn't work like a typical games console - a large bitmap display with no tiling, screen modes geared around text, a bunch of quirky legacy features  like the way hardware scrolling is split into two different bits etc.

By contrast the C64 hardware was basically designed as a games console and turned into a home computer in response to issues with the console market in the US. As a result its hardware is more like a traditional console (tiled display, sprites that can be multiplexed easily, sprite priorities and collision detection etc) and also doesn't suffer from having had to be shoehorned back onto an existing design.

siudym

Does access to ASIC registers, e.g. interfering with asic sprite ram, consume more cpu cycles in any way? (relative to other systems with hardware sprites). I noticed that too many calculations on sprites can significantly slow down the CPU (the amount of code is not that big, and eats up cpu cycles relatively heavily).

andycadley

No, if anything it's less because the sprites are entirely stored in hardware registers rather than in main memory (like most console designs) the ASIC doesn't ever need to stall the CPU to display sprites etc. Where it hurts though, is that you can't do something like change the entire sprite image by just re-pointing it at different memory - you always have to reload all the pixels (and do it individually). 

It's still an 8-bit CPU though, so obviously CPU time is very precious. And you annoyingly have to deal with 16-bit horizontal values (or scale them up at the last moment) because sprites positions are based on Mode 2 pixels.

GUNHED

With some nice routines one can update only the changed bytes in the hardware sprites. That's not very flexible (and not usable for generic systems), but still quick.

Sadly of every byte only four bits are uses, that double the amount up 'bytes to by updated' roughly and sadly. But hey, that's what we got - time to make the best out of it.
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

Powered by SMFPacks Menu Editor Mod