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

[nitrofurano]

hi! I'm curious about coding stuff for gx4000, specially via Pasmo (assembly) or Boriel’s ZX-Basic (basic, assembly or both - i have a special interest on this one, since i'm interested on help extending it to all z80 machines)


The situation is that i don’t know what to start trying to compile as ready tutorial examples, or documentation that might be helpful.


From what i tried to run those few games available on Mess, it seems not having a rom bios, so the rom start needs interrupt vector routines like master system, sg1000 and gamegear does? And why they need to be 128kb large? (anyway, i guess that memory paging for allowing cartridges up to 2 or 4mb might be possible electronically, but there are no emulators supporting it since there are no games using such paging?)


And about the rom start, is that possible or simple that our developed code can start at 0x0069, as i were doing for sg1000, master system and gamegear?


And i heard somewhere that the roms has some kind of encription or checksum (that "acid" chip?), and perhaps there might be some way to bypass this and make more easier to create homebrew stuff?


Please let me know how simple and possible is to do this, because it is quite sad seeing gx4000 being so empty of available titles, so i guess would be great homebrew stuff might have a great presence there

[arnoldemu]

hi! I'm curious about coding stuff for gx4000, specially via Pasmo (assembly) or Boriel’s ZX-Basic (basic, assembly or both - i have a special interest on this one, since i'm interested on help extending it to all z80 machines)

cool!

The situation is that i don’t know what to start trying to compile as ready tutorial examples, or documentation that might be helpful.

Go to Unofficial Amstrad WWW Resource

look for "An example setup for an Amstrad Plus/GX4000 cartridge".
The way my website is setup, I can't give a direct link, the redirect puts frames and that gets in the way of me copying and pasting direct links

My website has quite a selection of code showing how to do scrolling, split screen etc.

Also look on the docs section for "Arnold V" documentation. Also here on the wiki with some updates.

Also I and others are happy to answer any programming questions.

From what i tried to run those few games available on Mess, it seems not having a rom bios, so the rom start needs interrupt vector routines like master system, sg1000 and gamegear does? And why they need to be 128kb large? (anyway, i guess that memory paging for allowing cartridges up to 2 or 4mb might be possible electronically, but there are no emulators supporting it since there are no games using such paging?)

Correct. No bios.

You need some basic code to setup the hardware then you're ready to go.

512KB is the max without any extra hardware. The cartridge port has very limited signals so it is much harder to expand. You would need to use reads of specific memory addresses if you wanted to make larger cartridges.

And about the rom start, is that possible or simple that our developed code can start at 0x0069, as i were doing for sg1000, master system and gamegear?

it calls 0x0000. There is no rom header. So you can do a "JP 0x0069" at the beginning?

And i heard somewhere that the roms has some kind of encription or checksum (that "acid" chip?), and perhaps there might be some way to bypass this and make more easier to create homebrew stuff?

no encryption and no checksum.

The cartridge requires the acid chip inside it, if the acid and asic don't communicate the asic feeds z80 bad data and the game crashes.
So yes, it is required in some form. There is a simple piece of hardware Nilquader made which can make the asic work without an acid, but it's not always reliable. The best is a CPLD implementation of the acid. Again this code is available on the wiki.
 

Please let me know how simple and possible is to do this, because it is quite sad seeing gx4000 being so empty of available titles, so i guess would be great homebrew stuff might have a great presence there

agreed.

It has been discussed before.

We need cartridge cases/shells (can be extracted from existing carts if you really want), pcbs and acid replacements/alternatives (again can be extracted from existing carts - if you do, please use burning rubber ). So far there are some pcb designs, there is some acid replacement as cpld, but not put together and no cartridge cases either. There was talk of making them but nothing has materialised. It is sad

[MacDeath]

512K may still be quite more than enough to get huge games...

remember you can use some RAM to uncompress stuffs when needed.

Anyway I think such a big game should really include "drivers" so it can as well provide support for the PLUS (keyboards, Disk/Tape, Extra RAM) and be sure you also manage some extra peripherals (Mouse ? Analog port ? PlayCity ?) as well.

[SyX]

look for "An example setup for an Amstrad Plus/GX4000 cartridge".
The way my website is setup, I can't give a direct link, the redirect puts frames and that gets in the way of me copying and pasting direct links

Link

[nitrofurano]

it calls 0x0000. There is no rom header. So you can do a "JP 0x0069" at the beginning?

what i have for Master System, Game Gear and SG1000 coded on Boriel’s ZXBasic is this: (my concern is, since gx4000 is a z80, and the 0x00?8 (specially 0x0038 in the sega’s 8bit consoles - i can’t remember what 0x0066 is, perhaps start/pause button ) are interrupt vectors used from z80 by default, and the cartridge starts at 0x0000, it seems to have the same situation)

./library/smsboot.bas

Code: [Select]

asm
org $0000
boot:
di
im 1
ld sp,$dff0
jp main

pause:
push af
ld a,$ff
ld ($C000),a
pop af
retn

org $0038
push af
in a,($bf)
pop af
ei
reti

org $0066
jp pause

org $0070
main:
defb 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
defb 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
defb 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
defb 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0


end asm


(btw, the code there is actually starting at $0070, but it could be $0069, since "jp pause" takes 3 bytes starting from $0066 )

(the stuff i have for sega’s 8bit consoles can be find at Homebrew - SMS Power! from "nitrofurano", with sources - i imagine that can be somehow a good start for gx4000 )

so the idea is to code gx4000 stuff in this same process

[nitrofurano]

We need cartridge cases/shells (can be extracted from existing carts if you really want), pcbs and acid replacements/alternatives (again can be extracted from existing carts - if you do, please use burning rubber ). So far there are some pcb designs, there is some acid replacement as cpld, but not put together and no cartridge cases either. There was talk of making them but nothing has materialised. It is sad 

btw, did some make, or can make, models from these cases/shells for 3d printing, like Nes Cartridge (incl. Freecad model) by deepthought - Thingiverse ? would be amazing!

[arnoldemu]

You can use similar code to this yes.

The NMI (0x0066) is not used on GX4000.

On GX4000 it becomes a little more complex because you can:
1. Disable the ROM so that you can use the ram in the area &0000-&3fff.
2. You can choose which of 8 cartridge pages (16KB each) is at &0000-&3fff, so you could have a interrupt handler in each cartridge page.
3. Some cartridge ROM is accessible in the range &c000-&ffff.

[arnoldemu]

btw, did some make, or can make, models from these cases/shells for 3d printing, like Nes Cartridge (incl. Freecad model) by deepthought - Thingiverse ? would be amazing!

Yes that would be great.

I did give the dimensions of the case in another forum post. I don't know if somebody made a freecad model or not, they are free to use my information to make one

[arnoldemu]

I downloaded one of your productions.

I see the asm code and the .bas code.

I see your makefile/batch file.

So you can do a similar thing for mess/winape.

assemble it, use buildcpr tool and you have your cartridge you can use in mess/winape. If you want to burn it onto a rom for a real cartridge use the original binary file.

You will need to use a different library because the graphic chips are different compared to sms, but that is ok and I expected this.

So I think you will have fun writing for gx4000 in this way.

[nitrofurano]

btw, above, at 0x0038 what i have is related to "halt" for waitvbl - do gx4000 uses similar thing? (meaning, sorry for my ignorance about amstrad and gx4000, is it possible or should we add something for using "halt" as waitvbl, or we should only use delays with decrementing bc registers instead? )

[nitrofurano]

a question: for example, how easy is to "convert" these 16kb cartridges into gx4000-compatible?
16k ROM game development competition – finished | The Amstrad CPC news portal

[nitrofurano]

Yes that would be great.

I did give the dimensions of the case in another forum post. I don't know if somebody made a freecad model or not, they are free to use my information to make one

where from can we find it? perhaps i can start to do something on Blender, and someone else can convert it to 3d printing files - i only don’t know how accurate they will become

[nitrofurano]

my first test (not working, perhaps i'm missing something...)

[nitrofurano]

btw, via that .sh bash script, i'm finding that Mess emulator is opening rom files with the sizes 16kb, 32kb, 64kb, 128kb, 256kb and 512kb - 1024kb and above it shows segmentation error from terminal

so, what i wanted to do is to add some working example - the problem is that i'm a real newbie on coding on both amstrad and gx4000 this way! (and i'm struggling a lot to understand the examples available up to now - so if someone can help, please do, and thanks in advance! )

[mahlemiut]

Are you referring to ROMs or cartridges?  Carts can't really get bigger than 512kB.

[arnoldemu]

my first test (not working, perhaps i'm missing something...)

first build a cpr file using buildcpr. On my website under download section.
Unofficial Amstrad WWW Resource

http://www.cpctech.org.uk/download/buildcpr.zip

[nitrofurano]

Are you referring to ROMs or cartridges?  Carts can't really get bigger than 512kB.

in this case would be roms (but i guess it would apply on cartridge as well.
i think that once, Eduardo Robsy (Pitpan at Karoshi's msx forum), theoretically, the paging access can be almost infinite if we use msx/sega paging system (poking on rom areas that a paging chip would detect) applied on the cartridges (like 4mb using 1 byte for paging 16kb areas, 1gb (!) if we use 2 bytes, etc. ), so i guess it seems electronically possible, but a bit out of conventions or having default support from emulators

[nitrofurano]

first build a cpr file using buildcpr. On my website under download section.Unofficial Amstrad WWW Resourcehttp://www.cpctech.org.uk/download/buildcpr.zip

thanks, i'll try this soon, still today!   - btw, what is the difference between cpr and bin files, related to emulators? i saw that cpr has a header added on the bin file, but i don’t know what is that used for

[nitrofurano]

(this comment here was redundant and i erased it - how can we delete it?)

[nitrofurano]

first build a cpr file using buildcpr. On my website under download section.
Unofficial Amstrad WWW Resource

http://www.cpctech.org.uk/download/buildcpr.zip

thanks! i compiled and installed it fine with "make" and "sudo cp buildcpr /usr/bin/", and works fine on the script


the problem i think is on the example i tried to compile, the .cpr behaves just like the previous .bin , just a black screen appears (perhaps i'm missing something there, i just want to display a random display dump, or a "hello world", or something, for now)

[arnoldemu]

thanks! i compiled and installed it fine with "make" and "sudo cp buildcpr /usr/bin/", and works fine on the script


the problem i think is on the example i tried to compile, the .cpr behaves just like the previous .bin , just a black screen appears (perhaps i'm missing something there, i just want to display a random display dump, or a "hello world", or something, for now)

In the generated asm:

Code: [Select]

__START_PROGRAM:
    di
    push ix
    push iy
    exx
    push hl
    exx
    ld hl, 0
    add hl, sp
    ld (__CALL_BACK__), hl
    ei <<<<<<<

there is an ei here to re-enable interrupts.

After boot is finished, cartridge rom is still active in range &0000-&3fff. So when interrupt happens it will execute interrupt handler at &0038.
You will get a crash because the gx4000boot is not setup for this.

2. Your code is sitting in rom. __CALL_BACK__ variable in the asm will be in rom. It's read-only. It's value will not change. This will not work!

3. I am confused by ZXBASIC_USER_DATA. Is it relocated into RAM? The loop in your basic program stores it's value in ZXBASIC_USER_DATA. But because it's in ROM it's value is read-only and will never change, it will never go past 0. This will fail.

4. Is gx4000boot.bas filled so it goes up to 128? Your code assumes it running from 128 and you are using cat to join them. gx4000boot binary must be 128 bytes exactly. If not, it will fail.

Other solutions:

Your code is copied to ram. (Example is attached)

Your program runs from ROM but uses variables in RAM.

[nitrofurano]

In the generated asm:

Code: [Select]

__START_PROGRAM:
    di
    push ix
    push iy
    exx
    push hl
    exx
    ld hl, 0
    add hl, sp
    ld (__CALL_BACK__), hl
    ei <<<<<<<

there is an ei here to re-enable interrupts.

__START_PROGRAM is a kind of "garbage" generated by Boriel’s ZX-Basic i'm struggling to remove, but it is mostly not affecting the roms i were generating for Sega 8bit consoles (Master System, SG1000 and Game Gear) - so i guess it wouldn’t affect GX4000 as well

After boot is finished, cartridge rom is still active in range &0000-&3fff. So when interrupt happens it will execute interrupt handler at &0038.
You will get a crash because the gx4000boot is not setup for this.

yes, this is a question i have, actually.


at smsboot.bas that i have in my Sega 8bit examples ( like stuff at Homebrew - SMS Power! , from "nitrofurano" ), what i have related to this is: (starting from "org $0038")

Code: [Select]

asm

org $0000
boot:
di
im 1
ld sp,$dff0
jp main


pause:
push af
ld a,$ff
ld ($C000),a
pop af
retn


org $0038
push af
in a,($bf)
pop af
ei
reti


org $0066
jp pause


org $0070
main:


defb 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
defb 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
defb 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
defb 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0


end asm





but i don’t know what should be instead for GX4000, i imagine it needs to be very different

2. Your code is sitting in rom. __CALL_BACK__ variable in the asm will be in rom. It's read-only. It's value will not change. This will not work!

i don’t know, for some reason it is working fine on Master System, Game Gear, SG1000, Colecovision, MSX, etc... (perhaps i'm bypassing somewhere)

3. I am confused by ZXBASIC_USER_DATA. Is it relocated into RAM? The loop in your basic program stores it's value in ZXBASIC_USER_DATA. But because it's in ROM it's value is read-only and will never change, it will never go past 0. This will fail.

me too, but it never caused problems on Master System, Game Gear, SG1000, Colecovision, MSX...

4. Is gx4000boot.bas filled so it goes up to 128? Your code assumes it running from 128 and you are using cat to join them. gx4000boot binary must be 128 bytes exactly. If not, it will fail.

yes, on this i think i'm being careful enough...

Other solutions:

Your code is copied to ram. (Example is attached)

they also only display a black screen (all .cpr files)
(btw, all the code i compiled to rom files on these other hardware i were attempted, i used ram only for variables)

Your program runs from ROM but uses variables in RAM.

on SG1000 (as on Master System and Game Gear), i declare the variables first, like

Code: [Select]

dim oxsp as uinteger at $C000
(on Colecovision it's around $7000 (tiny ram available), and at MSX i use to start at $E000 )

the problem is that i don’t know where the ram on GX4000 is, or if it is based on memory paging, how can i switch them, which ones and to where

and thanks!

[andycadley]

At &0038 i'd probably just put:

Ei
Ret

For now. That'll stop interrupts from crashing the machine at least (later on you might want to instead jump to your own interrupt routine but that can wait). You don't need anything specific at the other restart points like &0066, because the machine doesn't use NMIs, so you can leave that entirely blank.

As for RAM, it's present in the entire address space, obviously at start up you will have the lower ROM enabled and thus READs will come from that instead. WRITEs to those addresses would go to RAM so you could just copy the first 16K over itself and then turn the lower ROM off and from then on you'll be working in a purely RAM environment.

[nitrofurano]

At &0038 i'd probably just put:

Ei
Ret

For now. That'll stop interrupts from crashing the machine at least (later on you might want to instead jump to your own interrupt routine but that can wait). You don't need anything specific at the other restart points like &0066, because the machine doesn't use NMIs, so you can leave that entirely blank.

...

at Push'n'Pop | Amstrad CPC Demoscene | Faster wait for the VBL
Push'n'Pop | Amstrad CPC Demoscene | Faster wait for the VBL i found:

Code: [Select]


waitvs:
ld a,&F5
in a,(&DB)
rra
jr nc,waitvs
so, i guess having it somehow at &0038 (that above might miss a "org &0038" and "ei" above and a "ret" below?), we might be able to use halt for wait-vbl? (i mostly use halt for wait-vbl on all z80-based machines i can)

[andycadley]

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.