about to start coding stuff for gx4000 with Pasmo or Boriel’s ZX-Basic

[nitrofurano]

You wouldn't want that happening on an interrupt, there are 6 per frame (unless you switch to the PRI or use DMA interrupts) so it'd slow things down massively. Trying to use HALT for v-blank on the Amstrad isn't really a good idea. You could put it on one of the other restart points and call it with a RST instead (assuming that's accessible from Pismo/Boriel) if you really want a single instruction way of doing it.

i didn’t know that...


in the meanwhile i tried to fix/improve my Boriel’s ZX-Basic example, still not working (only still that black display) - i added ei and ret at &0038 - and some questions related to how to access and page the ram (for now i'm looking for having 16kb or 32kb only (i guess we can have the ram starting at $C000 or $8000, display included?), for display and variables only, and all code at the rom, for now, just for attempting on simplifying my newbie-stage learning curve)


(for now, my first concern for now is having that feedback on being able to display something on the screen, and then starting to keep progressing after that)


about replacing halt for v-blank, i really have no idea how to do that, and where to start

[andycadley]

If you absolutely have to use HALT, your best bet would be to switch on the Plus Programmable Raster Interrupt (PRI) since this will disable the normal 6 fixed raster interrupts and replace them with one on a single scanline. By setting that to go off at a suitable point, you'd end up with something akin to a v-blank interrupt.

[nitrofurano]

would be that too hard to do?

[andycadley]

Not particularly hard no. With the ASIC registers paged in, just load the PRI register at &6800 with a value just larger than the number of scanlines in the display, say 201. That will replace the default interrupts with a single one that's triggered just after the display has been drawn. It's not quite v-blank, but it's probably functionally equivalent for most purposes.

Looking at your code, I also can't see anywhere that sets up the colour palettes, which is probably another reason the display just looks black (I'd assume emulators default to an all zero palette, not sure that's true of real hardware). So you probably also want to set that up by loading the ASIC palette registers too.

[nitrofurano]

Not particularly hard no. With the ASIC registers paged in, just load the PRI register at &6800 with a value just larger than the number of scanlines in the display, say 201. That will replace the default interrupts with a single one that's triggered just after the display has been drawn. It's not quite v-blank, but it's probably functionally equivalent for most purposes.

awesome! i'd like to see a snippet of it...

Looking at your code, I also can't see anywhere that sets up the colour palettes, which is probably another reason the display just looks black (I'd assume emulators default to an all zero palette, not sure that's true of real hardware). So you probably also want to set that up by loading the ASIC palette registers too.

perhaps a bunch of "out" instructions would do that, just for testing? how they would look like, as assembly code, in both cpc+ (4096 colours) and cpc (27 unique colours) modes?

[andycadley]

No problem, I've attached a couple to this post.

The first, ASIC PRI Sample, sets up a PRI just after the screen and then alternates the border colour a few times when it fires (so you can see where it is)

The second, ASIC colours sample, draws a pattern of stripes on the screen in each INK colour and then resets the palette into a series of incrementing yellow/cyan colours. It dynamically sets the PRI to trigger at a couple of points on the screen as a way of getting more onscreen colours (and is why I wouldn't recommend think of HALT as a frame syncing mechanism)

Note that both the above examples leave the ASIC registers paged in at &4000 (the Plus hardware is memory mapped rather than IO mapped). In a real world piece of code, you're more likely going to want to switch the ASIC on/off so that you can use the RAM in that address space.

Setting colours the old-school way is just a matter of OUT-ing the correct values to port &7fxx (a PEN select then an INK set), although I really wouldn't recommend it if you're running from a cartridge, the Plus palette is just so much nicer. :-)

[nitrofurano]

thanks!

No problem, I've attached a couple to this post.

The first, ASIC PRI Sample, sets up a PRI just after the screen and then alternates the border colour a few times when it fires (so you can see where it is)

The second, ASIC colours sample, draws a pattern of stripes on the screen in each INK colour and then resets the palette into a series of incrementing yellow/cyan colours. It dynamically sets the PRI to trigger at a couple of points on the screen as a way of getting more onscreen colours (and is why I wouldn't recommend think of HALT as a frame syncing mechanism)

Note that both the above examples leave the ASIC registers paged in at &4000 (the Plus hardware is memory mapped rather than IO mapped). In a real world piece of code, you're more likely going to want to switch the ASIC on/off so that you can use the RAM in that address space.

tried that - compiled, but it is also all black as well - i have no idea what could be wrong there (i'm attaching them back as well)

Setting colours the old-school way is just a matter of OUT-ing the correct values to port &7fxx (a PEN select then an INK set), although I really wouldn't recommend it if you're running from a cartridge, the Plus palette is just so much nicer. :-)

yes, since it’s for GX4000 firstly (for lots of reasons: the resulting materials are rom only, there is a need to increase the titles for GX4000, from my humble attempts i want to humbly motivate more people creating stuff for GX4000, etc.), i want to focus on the Plus palette mostly - the fact is that i'm also curious about the "default" palette as well, since i'm curious about starting Amstrad CPC later, on Boriel’s ZX-Basic Compiler

[andycadley]

I didn't bother fully configuring the CRTC, so the screen wouldn't be enabled, because I was just calling it from BASIC. You'll need to include the CRTC setup code from your previous boot code if you want to put it in a cartridge.

Setting up colours the old school way is jut a matter of doing something like:

Ld bc, &7f00
Out (c), c ; Select Pen 0
Ld a, &40
Out (c), a ; Select White

The wiki details the bit combinations required to select functions when writing to the gate array.

EDIT: Also when I setup Mode 0, it's disabling the ROMs, you'll need to tweak that slightly if you're running it from cartridge too (otherwise the code will be paged out from under itself!). Probably also need to set the stack up somewhere sensible too, between &8000 and &bfff to avoid the ROM, ASIC and display area.

[nitrofurano]

I didn't bother fully configuring the CRTC, so the screen wouldn't be enabled, because I was just calling it from BASIC. You'll need to include the CRTC setup code from your previous boot code if you want to put it in a cartridge.

i confess i'm a bit lost, i'm a newbie about CPC and GX4000!

Setting up colours the old school way is jut a matter of doing something like:

Ld bc, &7f00
Out (c), c ; Select Pen 0
Ld a, &40
Out (c), a ; Select White

yes, thanks, something is starting to appear on the zxbasic example (attached in this message) - but it seems that something there is all out of control... (the display is getting filled from the end to start and slowly, quite weird)

about that asm examples for pasmo, i'm lost there, i don't know what to do with that then... (seems simple when we know exactly what each instruction exactly does, which is not my case yet...)

The wiki details the bit combinations required to select functions when writing to the gate array.

where? i think i only found about those colour palette index codes - Video modes - CPCWiki

EDIT: Also when I setup Mode 0, it's disabling the ROMs, you'll need to tweak that slightly if you're running it from cartridge too (otherwise the code will be paged out from under itself!). Probably also need to set the stack up somewhere sensible too, between &8000 and &bfff to avoid the ROM, ASIC and display area.

somehow, in this example i’m attaching now, it seems to write between $C000 and $FFFF, when i imagined it would between $4000 and $7FFF - what do you think is going wrong there?  (i'm actually trying to set the stack somewhere there as well)

i actually wanted to use the ram between $C000 and $FFFF, or between $8000 and $FFFF , and having the most possible for rom starting from $0000

[andycadley]

No problem, I've not used Pasmo or ZXBasic (really must give them a go) as I tend to stick to pure asm using the built in assembler in WinAPE these days. But hopefully I can point you in the right direction.

Details on the Gate Array for colour manipulation the old way is at Gate Array - CPCWiki - the GA is also used for things like ROM/RAM banking and changing Mode, so it's worth a bit of a read.

For the stack pointer, your safest bet is to initialise it to &c000 (although you should probably put it in your boot code). The stack grows downwards in memory and doesn't use the byte at the address you first load so it'll go from &bfff down towards 0. That's probably the safest bit of memory as things stand since you have the Lower ROM enabled in 0-3fff, the ASIC enabled at 4000-7fff and the screen located at c000-ffff. :-)

I'm not sure what you're trying to do by writing to &d008 and &d009, that doesn't seem to accomplish anything at all.

What I really can't understand though is why the compiled code in the cpr file has placed a JP &00b8 at &00b8, right after you set SP. That just ends in an infinite loop, so the rest of your code is never getting run.

[nitrofurano]

No problem, I've not used Pasmo or ZXBasic (really must give them a go) as I tend to stick to pure asm using the built in assembler in WinAPE these days. But hopefully I can point you in the right direction.

thanks!

Details on the Gate Array for colour manipulation the old way is at Gate Array - CPCWiki - the GA is also used for things like ROM/RAM banking and changing Mode, so it's worth a bit of a read.

yes, only now i'm figuring out better what is there

For the stack pointer, your safest bet is to initialise it to &c000 (although you should probably put it in your boot code). The stack grows downwards in memory and doesn't use the byte at the address you first load so it'll go from &bfff down towards 0. That's probably the safest bit of memory as things stand since you have the Lower ROM enabled in 0-3fff, the ASIC enabled at 4000-7fff and the screen located at c000-ffff. :-)

thanks! i guess it starts to work now (added in the attachment)
(btw, the only situation i'm seeing now is that the colours looks shuffled, instead of "red, green, blue and yellow", it appears "blue, red, blue and yellow" )

I'm not sure what you're trying to do by writing to &d008 and &d009, that doesn't seem to accomplish anything at all.

just a test, trying to poke something on the screen (actually something appeared there)

What I really can't understand though is why the compiled code in the cpr file has placed a JP &00b8 at &00b8, right after you set SP. That just ends in an infinite loop, so the rest of your code is never getting run.

i think that was "loop02:goto loop02" on the basic part - the fact is that there is no difference having that there or not - for example, try replacing that with 3 "nop" operands, and the result will be the same... :S

and btw, how cpcplus palette works, from "out" operands? (in an example, just like that you did about the 27-colour cpc palette - i want to try it as well! )

last edit: adding another example, using mode 0 - what i don’t know is how sizes and locations works...

[nitrofurano]

found it - i'm testing overscan there - the problem is that there are 16kb ram banks (the display appears repeated somehow), i imagine that we need 32kb ram for overscan - perhaps from $8000 to $FFFF (i don’t know how to do that...)

[andycadley]

You may find the colour thing is just down to the encoding of pixels in the screen ram, as it's not necessarily as obvious as you might first think.

Overscan is a tricky one, you have to put the CRTC in 32K mode and the memory arrangement gets a bit tricky. As it stands with the Lower ROM turned on and the ASIC paged in, you'll find it tricky to do. You kinda need to get used to the whole paging mechanism to be able to work effectively with such a large amount of the RAM dedicated to the display.

The Plus colour palette, along with all the other new functionality, isn't IO mapped so you can't access it via OUT instructions. Instead you have to page in the ASIC registers (your boot code already does this). The palette registers are then located between &6400 and &641f, two bytes  per PEN. They're followed by the Border colour at &6420 and &6421. More details of the ASIC registers is at "Arnold V" Specification - Issue 1.5 - 10th April 1990
"Arnold V" Specification - Issue 1.5 - 10th April 1990

[nitrofurano]

You may find the colour thing is just down to the encoding of pixels in the screen ram, as it's not necessarily as obvious as you might first think.

Overscan is a tricky one, you have to put the CRTC in 32K mode and the memory arrangement gets a bit tricky. As it stands with the Lower ROM turned on and the ASIC paged in, you'll find it tricky to do. You kinda need to get used to the whole paging mechanism to be able to work effectively with such a large amount of the RAM dedicated to the display.

yes, i'm afraid that will take a while (unless someone else might try to do that on ZXBasic as well! )
i imagined that this would be as simple as for example, having the display ram between $8000 and $FFFF, and since whole 32kb seems to be not completely used, we could use that for other stuff too (variables, stack, etc.)

The Plus colour palette, along with all the other new functionality, isn't IO mapped so you can't access it via OUT instructions. Instead you have to page in the ASIC registers (your boot code already does this). The palette registers are then located between &6400 and &641f, two bytes  per PEN. They're followed by the Border colour at &6420 and &6421. More details of the ASIC registers is at "Arnold V" Specification - Issue 1.5 - 10th April 1990
"Arnold V" Specification - Issue 1.5 - 10th April 1990

thanks!


and i didn’t know that - would this mean that, the situation i have now is that i only have between &0000 and &3FFF for rom and everything else for ram, or just the fact that i poke between &6400 and &6421, even on rom, the machine assumes it is for the palette, just like Sega Master System and some MSX rom pagers (like ascii8k and ascii16k) uses for cartridge rom paging? (btw, in theory, that would be how GX4000 could support over 512kb of cartridge roms (up to 4mb is 1 byte is used, and up to 1gb if 2 bytes are used ) - people here experienced in electronics would confirm it  - the only problem of this is that it is not conventional to the GX4000 specifications, and no emulator is supporting it yet)




another question: is the GX4000 joystick using the keyboard connectors (as the feedback i got from Mess emulator)? - the code i found on the wiki here looks a bit tricky, wasn’t that just setting and reading i/o ports? (on machines like ZX-Spectrum, MSX, Mattel Aquarius, and so on, doing this is extremely simple - i really wonder how complicated it is on CPC... )

[andycadley]

Yeah, in theory you can use the unused bits of the display memory for other things, but because the display storage isn't entirely linear it's takes a bit of effort to figure out where the "holes" are. I'd stick to a 16K display to start with. No point overcomplicating things to begin with. 

As it stands, your memory map looks a bit like this:

&0000 - &3fff - ROM (writes will go to the underlying RAM page though)
&4000 - &7fff - ASIC registers
&8000 - &bfff - RAM (with the stack at the top end)
&c000 - &ffff - Screen RAM

So, as you can see any write to say &6400 will write into the ASIC and change the palette. Normally you'd not leave the ASIC paged in, so that the RAM there is usable to. And you just switch it in and out when you're actually making changes to the registers.

The Plus can support a maximum of 512k cartridge ROM, split into 16K chunks. The first 8 of which can paged in at &0000 or &c000, the rest can all be paged in at &c000. No existing cartridges are actually that large however. 

Reading the keyboard/joystick is a bit of a pain on the CPC/GX, because it all involves a slightly convoluted mapping via the PPI. You should be able to get by with a generic routine though (I'm sure there is one around here). On the GX you only need worry about the joysticks and the P key, which is what the pause button maps to. 

[arnoldemu]

@nitrofurano:

I like what you are doing. I like that you are investigating the gx4000, cartridges and writing code using zxbasic. I think it's a good plan and I look forward to seeing the results of your work.
Keep going.

Myself I work with either assembler (I use pasmo) or C (I use sdcc).

As you can see from the forum we are all willing to help!

[nitrofurano]

Yeah, in theory you can use the unused bits of the display memory for other things, but because the display storage isn't entirely linear it's takes a bit of effort to figure out where the "holes" are. I'd stick to a 16K display to start with. No point overcomplicating things to begin with.

that was mostly by curiousity!  (and the excitement on seeing stuff working! )
and yes, it's quite interesting "gymnastic" to figure out how this whole paging system works!

As it stands, your memory map looks a bit like this:
&0000 - &3fff - ROM (writes will go to the underlying RAM page though)
&4000 - &7fff - ASIC registers
&8000 - &bfff - RAM (with the stack at the top end)
&c000 - &ffff - Screen RAM

thanks!

So, as you can see any write to say &6400 will write into the ASIC and change the palette. Normally you'd not leave the ASIC paged in, so that the RAM there is usable to. And you just switch it in and out when you're actually making changes to the registers.

my concern mostly was that i might need between &0000 and &7FFF for rom

The Plus can support a maximum of 512k cartridge ROM, split into 16K chunks. The first 8 of which can paged in at &0000 or &c000, the rest can all be paged in at &c000. No existing cartridges are actually that large however. 

my first curiousity about "large" rom files was for testing stuff like ZX BASIC:Released Programs - MSX - BorielWiki - that is a slideshow (106kb each picture, 256x424 in yjk colour format, uncompressed) filling whole 4mb of a memory-paged rom using ascii16k paging system - this was a kind of previous level of a picture-based game ( a bit like ZX BASIC:Released Programs - BorielWiki ) that i want to have similar stuff for gx4000

Reading the keyboard/joystick is a bit of a pain on the CPC/GX, because it all involves a slightly convoluted mapping via the PPI. You should be able to get by with a generic routine though (I'm sure there is one around here). On the GX you only need worry about the joysticks and the P key, which is what the pause button maps to.

thanks for confirming how painful it is! - i actually will have to put some hands on it soon, try to transform what is available in the wiki in a kind of library (like those i started in the last attachment i added here in this thread)

@nitrofurano:
I like what you are doing. I like that you are investigating the gx4000, cartridges and writing code using zxbasic. I think it's a good plan and I look forward to seeing the results of your work.
Keep going.

thanks!
there are, mainly, for 2 purposes, that i'm attempting this:
- i want to help zxbasic becoming a far more popular tool that it is, try to extend it to the most wide range of z80-based existing hardware (even those most obscure from eastern Europe), and sharing the idea of how simple can be creating stuff with that.
- it is sad seeing a console like GX4000 almost abandoned in the scene because the lack of "classical" titles, when the homebrew scene can help a lot on "fixing" this situation, and from my humble part trying to contribute on it.
The next step will be CPC (the whole range besides GX4000), PCW, etc. - but i really wanted to focus on GX4000 first because of the second purpose i cited above

Myself I work with either assembler (I use pasmo) or C (I use sdcc).
As you can see from the forum we are all willing to help!

thanks!

[andycadley]

Good stuff. 

As a long time advocate of the Plus/GX4000 hardware it's always good to see someone trying new stuff out with it. Bit busy this week but I'm definitely going to have to install Pasmo/ZXBasic and see what it can do. Hopefully we can find ways of making some of this stuff a bit easier!

[CraigsBar]

Anything that makes use of the extended features on my plus is good news. It seems such a waste to just use classic Cpc stuff on them.

[nitrofurano]

thanks a lot for the feedback!   


btw, while adding new commands to the library (like setting the screen mode, entering cpc+ as hexcolour on the palette ( for example, #928E76  from Palette / Hard Mix :: COLOURlovers becomes #987 in 12bit, and $987 as value for there), etc. ), i found that i'm struggling on setting the screen size and offset again and again (crtc stuff) - the idea is that the boot might have some default stuff for starting, and then we could change it via commands from these libraries like those i'm attempting on creating - i guess it is something wrong there?

[Xifos]

Hi,

I wrote corrections in your sub cpcscreensize.
When you select crtc register, it's ok.
ld bc,$bcNN
out (c),c

But when you write the value, it must be on $bdNN...

Code: [Select]

sub cpcscreensize(txsz as uinteger,tysz as uinteger):
  asm
    ld bc,$bc01
    out (c),c
    ld a,(ix+4) // for the crtc register value it must be $bdxx not $bcxx
    inc b // so inc b, or ld b,$bd
    out (c),a
    ld bc,$bc06
    out (c),c
    ld a,(ix+6) // same here
    inc b
    out (c),a
    end asm
  end sub



[nitrofurano]

Hi,

I wrote corrections in your sub cpcscreensize.
When you select crtc register, it's ok.
ld bc,$bcNN
out (c),c

But when you write the value, it must be on $bdNN...

Code: [Select]

sub cpcscreensize(txsz as uinteger,tysz as uinteger):
  asm
    ld bc,$bc01
    out (c),c
    ld a,(ix+4) // for the crtc register value it must be $bdxx not $bcxx
    inc b // so inc b, or ld b,$bd
    out (c),a
    ld bc,$bc06
    out (c),c
    ld a,(ix+6) // same here
    inc b
    out (c),a
    end asm
  end sub



thanks! working fine now!

[nitrofurano]

testing the joystick, and writing some text (btw, i guess Mess doesn’t emulate pause button from GX4000 hardware)

[CraigsBar]

testing the joystick, and writing some text (btw, i guess Mess doesn’t emulate pause button from GX4000 hardware)

the pause button is just mapped to "p" if I recall correctly.

[nitrofurano]

yes, thanks for confirming! (i think it was mentioned in this thread before)


btw, i added the keymap line related to "p" key, in the case people might want to try it on other emulators (i don’t know which good GX4000 emulator is there for GNU/Linux besides Mess)


about the ZX-Basic wiki page, i'm starting this one:  ZX BASIC:Released Programs - AmstradCPC - BorielWiki  (all people are welcome on adding stuff there, as far as they are made by ZX-Basic Compiler! )