cartridge filesystem

[arnoldemu]

I have attached to this post a proof of concept file created using my "cartridge filesystem" tools.

It's a "direct to cartridge" port of Solomon's Key. (I didn't even bother to set the colours/mode for the title screen. Now I just have it working, I'll add the colours from the solomon's key + hack. Can anyone provide + colours for the title screen?

This is an example that should work on gx4000 etc.

This solution involves a little more work than No$Cash solution, but it opens up the full cartridge space, and works on gx4000.

The data is stored on the cart and copied into RAM. It's easier to do it this way. It's "loaded" from the cart - this is why I call it a filesystem. At the start of the cart data you will see the directory at offset &b.

This represents another way to have games on cart.

In the directory:

First byte is cart page (&80 etc)
next 2 bytes are address to read from (pages cart pages into upper rom area) so address is always from &c000 onwards.
next 2 bytes are the length.

and that is it.

So you can see there are 4 files in there.

1 small "boot" program, copied to &4000 and run from there,
1 screen, 1 main file, and another screen.

The "boot" program sets up the hardware state, loads the first to the screen, next to &100, next to the screen and executes the game.

An improved boot program will fade the title screen in and out (with correct colours), load up the main exe with plus colours.

I will post the tools and sources soon so others can use it to make plus games.

EDIT: Added the Plus colours from the Plus hack.

[Trebmint]

Certainly works and I'll be using this method for sorcery. Good stuff... plus with an extra 16k bank from the cart we can add some nice extra stuff too

[Kris]

Works perfectly, that's a great news for Plus users that this tool from noCash is back



Edit: I just burn an Eprom with the .CPR tranfer to .BIN file and it doesn't works on real Plus; screen freeze .

[Trebmint]

Works perfectly, that's a great news for Plus users that this tool from noCash is back



Edit: I just burn an Eprom with the .CPR tranfer to .BIN file and it doesn't works on real Plus; screen freeze .

You mean people can sell an unmodified GX4000 cart of Roland in Time on ebay for £100 haha.... hmmm actually 

[Devilmarkus]

Would be interesting to know, if the CPR works on a real GX4000.
Did anyone try it yet?

(In my lousy Java emulator it doesnt even startup)

In rest: Nice work!

Whoops... Edit: Seen that Kris already tested it... Sad...

Does it also show grey border and black screen on the real thing?

[Kris]

I will post a picture of the screen on real Plus asap


EDIT: here is the 1st attempt:

[arnoldemu]

Works perfectly, that's a great news for Plus users that this tool from noCash is back



Edit: I just burn an Eprom with the .CPR tranfer to .BIN file and it doesn't works on real Plus; screen freeze .

This tool is not nocash's tool. It's my own.

  Sad it doesn't work on real plus. I didn't test it yet.

BIN file is attached.

notice it's not an exact rom size.

I will make sure it works on plus and gx4000.

[gerald]

This tool is not nocash's tool. It's my own.

  Sad it doesn't work on real plus. I didn't test it yet.

BIN file is attached.

notice it's not an exact rom size.

I will make sure it works on plus and gx4000.

It get stuck at the game title screen waiting for a keypress.
Comparing the behaviour on winape and the real cpc, I notice that no interrupt occurs on the real cpc.
Since the title screen waiting loop (23BA-23D5) rely on data (keyboard line status) updated by interrupt, we get stuck there.

Question is why interrupt does not occur on real HW, and why this is different on emulator

[arnoldemu]

It get stuck at the game title screen waiting for a keypress.
Comparing the behaviour on winape and the real cpc, I notice that no interrupt occurs on the real cpc.
Since the title screen waiting loop (23BA-23D5) rely on data (keyboard line status) updated by interrupt, we get stuck there.

Question is why interrupt does not occur on real HW, and why this is different on emulator

great thanks for the analysis. Will fix that (on emu and in the code).

[gerald]

great thanks for the analysis. Will fix that (on emu and in the code).

Any idea why there is a different behaviour regarding IRQ ?

[arnoldemu]

Any idea why there is a different behaviour regarding IRQ ?

I have worked out what is wrong.

The code does turn on interrupts, but the z80 is in the default interrupt state of IM 0.
The value on the bus supplied by the asic... well it's not going to be ff like it mostly is on CPC, so it jumps to the wrong place and doesn't execute the instructions.
In an emu, chances are the ram is probably filled with zeros, so it just happens to fall through and work.

So I added an "im 1" instruction into the setup code

Will check what happens in my emu because it just happens to work on mine when it shouldn't.

new files attached.

Do these work better?

[gerald]

I have worked out what is wrong.

The code does turn on interrupts, but the z80 is in the default interrupt state of IM 0.
The value on the bus supplied by the asic... well it's not going to be ff like it mostly is on CPC, so it jumps to the wrong place and doesn't execute the instructions.
In an emu, chances are the ram is probably filled with zeros, so it just happens to fall through and work.

So I added an "im 1" instruction into the setup code

Will check what happens in my emu because it just happens to work on mine when it shouldn't.

new files attached.

Do these work better?

Now that's better  .

[arnoldemu]

So a lesson in cartridge programming 

* When cart is started, cart page 0 is readable in the range &0000-&3fff and &c000-&3fff.
* Interrupts are disabled.
* You can write to the ram under the rom (ideal for transfering data from rom to ram).
* Make sure you set the Z80 interrupt mode to 1 (or 2 if you want that)
* Make sure you setup the PPI and CRTC (otherwise you'll get no keyboard input or screen display).
* Colours will be random, so you need to initialise those.
* Initialise the stack to be within the main 32k ram (&4000-&c000). I put it at &c000 and let it grow down.

EDIT: These are the lessons I learnt and I wanted to share them with you.

[arnoldemu]

EDIT: here is the 1st attempt:

Nice pic.

I forgot to setup the border colour. 

[Gryzor]

Good stuff... plus with an extra 16k bank from the cart we can add some nice extra stuff too

Like a cracktro

[gerald]

EDIT: here is the 1st attempt:

I did not get the same border color, mine was always orange 

[Kris]

I did not get the same border color, mine was always orange 

Do you mean on real CPC+ ?


I'm erasing some eprom at the moment, I wil test the new file in few minutes

[Kris]

Works perfectly on real machine now! 


Have a look:

[gerald]

Do you mean on real CPC+ ?

Yes, with the 1st version arnoldemu provided. The last one has the correct black border.

I'm erasing some eprom at the moment, I wil test the new file in few minutes

erasing, what is this ? 

[Kris]

You know what I mean even if my english is not perfect

[gerald]

I did not get the same border color, mine was always orange 

Well, greeninsh orange, I would say 
[attachimg=1]

And on a gx4000
[attachimg=2]

[gerald]

You know what I mean even if my english is not perfect

Your english is quite good, at least as good as mine 
Well, in more than 20 years playing with HW, I never erased an eprom.

[Kris]

It is the wording used in my software to manage Eproms, so I use it   but if a UK native guy can help us to improve our English it could be great


Anyway, back to the orignal subject: strange behaviour between both machine....are you using the final .bin file ?

[gerald]

It is the wording used in my software to manage Eproms, so I use it

And it's the right word.
I am currently using this :
[attachimg=1]

[Kris]

OK, now I understand why we have 2 differents results 


HW emulator ?