GX4000 Multicart/SD card

[endangermice]

[size=78%]Excuse me, but that's the most time consuming, most hard and simply worst idea. To move a Cartridge game from Cart to Disc it needs a major rewrite including basic things sprite routines and tile display.[/size]And I will also tell you why. Carts have a kind of banking which does not exist for disc games, you can not just use E-RAM instead of load from disc. The cartridge ROM banks can be banked it at every address out of &0000, &4000, &8000, &C000. So they can always access different screen RAMs and can use direct transfer of sprite or tile data while regular programs must get it from expansion RAM an this can only be &4000 or &C000 (the latter one is used very seldomly only!).

Fair enough, thanks TFM - you know the ins and outs far better than I, I appreciate your candid and honest response. I felt that the issue might be along the lines of what you say - solid state compared to even fast disk is practically instantaneous and works in a different way. Still it was worth  posing the question, just to get it out of the way . I think Bryce's idea of a mega EPROM sounds like the easiest approach.

In a way it's frustrating than there aren't more cartridge games to justify the production of a hardware asad cartridge solution, but the reality is that very few were made. It's a real pity we never saw the Plus features taken to the max but sadly it was all too little too late.

[TFM]

The advantage I see is that the cart offers instant access to data. 128k of the Rom can be accessed at any page in memory, the remainder accessible in the high page. It is similar to having 128k ram on plus.

Sorry, no. You can bank in a 16 KB ROM (of the fist 128 KB ROM) at any block, but RAM banking only works for the block at &4000 and few can be banked in at &C000, but f.e. never at &8000 or &0000 (except you bank in 64 KB at once).
Cartridges offer efficient memory management not to be seen before. And if you step back from Cart games to Disc games then this can be a terrible amount of effort. Also the result may work slower.

[arnoldemu]

Sorry, no. You can bank in a 16 KB ROM (of the fist 128 KB ROM) at any block, but RAM banking only works for the block at &4000 and few can be banked in at &C000, but f.e. never at &8000 or &0000 (except you bank in 64 KB at once).
Cartridges offer efficient memory management not to be seen before. And if you step back from Cart games to Disc games then this can be a terrible amount of effort. Also the result may work slower.

But how much actual advantage does it give? Can you give an example that actually shows how much speed improvement or advantage this will give???

I have heard claims but not yet seen any solid evidence.

I don't have the time at the moment to test any of these claims.

[andycadley]

Take, for example, my own JSW+. It has around 40K of packed hardware sprite images. Since you need the game code and display file, at least some of that has to live inside the banked RAM. But if you use the "normal" banking configuration, which pages in at &4000 you can't copy directly out of the banked RAM into the ASIC sprite registers (and you really need to do this, JSW+ spends a lot of time reloading the sprite registers).

To get around that it has to use the "alternate" configurations 1 & 2, with the main engine code sitting in Page 7. Unfortunately that combination then makes accessing Page 3 awkward, since the only way to bring it in whilst retaining the core code in situ is banking config 3, but that again places Page 3 right underneath where the ASIC pages in. The other RAM combinations are a pain because they don't give you a clean place to keep the stack and interrupt vectors, which is important when you're using Raster interrupts for palette effects.

And JSW+, though sprite heavy, isn't even doing anything that clever. It doesn't need to double-buffer the display for example (since it's sprite usage is 100% H/W and the background only changes on a flip screen basis), which is something a more animated scrolling title would possibly want to do. Nor does it use the hardware splitting capabilities, which are yet more RAM intensive.

The ROM mapping capabilities go a long way to making this a much less painful situation. You can more effectively bring in precisely the data you need in places which don't interfere with the ASIC register mappings. Add to that the fact you can use the write-through capability of ROM mapping to transfer data in (giving you an effectively extended address range). The GX hardware was just really designed around the idea that it really only needed to work well for ROM based software.

[arnoldemu]

I get it, but for a person who doesn't t know about the hardware, then a disc version would look the same as a cart version, therefore although coding for us is easier in this respect, to the user there is no difference. So why bother with cart?

I could show how instant loading is a great thing, in a way that the user can appreciate. But how to show that having a different memory configuration can make an improvement is harder to show, unless it means more fps and more sprites.

[TFM]

But how much actual advantage does it give? Can you give an example that actually shows how much speed improvement or advantage this will give???

Sure... for 128 KB...:
- You want to animate sprites, your sprite data is in E-RAM, so it needs to be buffered in somewhere else than &4000-&7FFF. From Cart sprite data can be constantly copied to the hardware sprites w/o buffering them. Huge speed up.
- Your tile data is in E-RAM or in Cart. If your screen is at &4000 (double buffering). Cart allows you direct transfer of tile data into V-RAM, while it needs to be stored somewhere else when coming from E-RAM. And you probably won't even have free RAM left.


For 64 KB systems (GX f.e.): Having no Cart means to constantly load from disc. Let's assume there is double buffering or overscan. Sorry not much RAM left.


The problem is that the block at &4000 is the block which contains all Plus features, all E-RAM access, and probably also a screen block. And data must be transferred from one to the other. This needs a buffer and doubled data transfer times. With the cart you just don't have that problems any longer.


On a regular 128 KB CPC I already have similar problems when using overscan (means 32 KB screen RAM). The main program must be put in a block smaller than 16 KB! (Which really suxx!).

[CraigsBar]

Hmmm . Probably get shot down here... But... As an idea how feasible is it to emulate the whole cart in software with a usb interface (or similar) directly to the cart slot?

I mean if a raspberry pi type device could be used to emulate the acid, the game Rom and it's gpio pins or usb host used to connect to the cartridge bay directly, would this not solve the cost issue? Just a thought. And think of the spangly interface you could design for a pi to load images etc.

[CraigsBar]

Sorry , I think tapatalk had a Fritz for a minute. Now how to delete the 3 dupes.

[TFM]

Gryzor deleted the delete feature (suxx!). So you can change them but not delete them. Just post a nice picture. 

[arnoldemu]

On a related note.

I saw a disc version of Navy Seals for C64. It had been converted from cart to run from disc. This is more possible on the C64 because some games are written as if the cart was a filesystem.

The loading time was not fun even with a fast loader, so although it was the same game, with all the same features and on disc, I am sure it would be more enjoyable on cart because the loading times would be non-existant.

People can then say: but the cpc loads faster than the c64.

This is true, but still there will be a significant delay. So instant loading is still a great thing. So putting a game onto cart and have the instant loading can make it more fun to play.

It's not the only reason, but it does work well for a game that has many parts and multi-load.

[TFM]

Also, if you develop specifically for using a Cartridge, you will do it different as if you would target a disc and 128 KB RAM f.e.
Today we still do 64 KB games, because our time is limited. But we should move on to a game which at least once really shows off what the CPC can do. And we do have couple people here - them working together on a game could really make the difference. However, everybody seems to be busy enough already (own projects f.e.).


Back on topic! How could we realize such a SD-card (or whatever) Multi-Cartridge thing?

[andycadley]

I could show how instant loading is a great thing, in a way that the user can appreciate. But how to show that having a different memory configuration can make an improvement is harder to show, unless it means more fps and more sprites.

I think more fps and more sprites is entirely viable. But it's a big ask for people to commit to developing a true, cart-only title when there isn't any way for them to ever try it out for real. I'm tempted to do something though, just to try and demonstrate the point.

Hmmm . Probably get shot down here... But... As an idea how feasible is it to emulate the whole cart in software with a usb interface (or similar) directly to the cart slot?

I mean if a raspberry pi type device could be used to emulate the acid, the game Rom and it's gpio pins or usb host used to connect to the cartridge bay directly, would this not solve the cost issue? Just a thought. And think of the spangly interface you could design for a pi to load images etc.

I believe this has been suggested before and the problem is just that devices like the pi aren't fast enough to emulate the Acid chip and respond to memory requests in a way that would be viable.

[CraigsBar]

I believe this has been suggested before and the problem is just that devices like the pi aren't fast enough to emulate the Acid chip and respond to memory requests in a way that would be viable.

perhaps the same theory to a pc them perhaps? No gpio would be more tricky I suppose

[Bryce]

Sorry , I think tapatalk had a Fritz for a minute. Now how to delete the 3 dupes.

Removed.

Bryce.

[arnoldemu]

Andy, do a small demonstration. A cart version and the equivalent for disc, and show the source. People can get an idea by using an emulator. Of course real hardware is best because of accuracy. This would be perfect to prove it and also show others who want to use the same idea in their games.

[TFM]

Let's say.... this is the FutureSoft multicart (of course it will never exist, but that would be it the way I could imagine one):

- Using the idea of Bryce and do a 'man in the middle' solution. So no ACID is needed.

- Using SRAM for a 512 KB ROM Cartridge (maybe even more for games as big as not to be seen yet).

- How to write to the SRAM? That's the tricky part, beause the Cartridge port does not allow to write to it. Solutions are:

-- Apply a write protocol, which is encoded by reading from different addresses (slow, complicated, but doable from the CPC).

-- Add an SD-Card or any other mass storage. Some simple solution like jumpers or even pressing a button could select the Cartridge-Image (quick, much choice, still nothing else needed).

-- SRAM is connected to a RS232 interface (or similar), so in can be driven by a PC or the CPC-Booster.

I'm sure as soon as we would have a Multi-Cartridge we would have people doing games for it. (Personally I still wait for somebody to make me Cartridge shells...).

[endangermice]

I'm sure as soon as we would have a Multi-Cartridge we would have people doing games for it.

That hits the nail on the head for me - despite the lack of plus games available invite no the creation of new ones would be fantastic, I'd love a go myself - I've done C64 and CPC stuff but would love a chance to do some plus stuff without restriction.


I think the problem still boils down to cost and ultimately that's driven by demand. This is why I suggested the disk transferral ok it's expensive in terms of programming time but cheap in terms of hardware cost. However it seems to be becoming clear that transferring cart to disk is highly difficult if not impossible and perhaps not even desirable!


It is an interesting problem to solve though and I wish I had the Plus knowledge to begin to fathom a solution.

[TFM]

Well, yes, you got a point there. People like things cheap, on the other hand look for which crazy crap the folks waste their money and then it all becomes quite relative 

[andycadley]

Andy, do a small demonstration. A cart version and the equivalent for disc, and show the source. People can get an idea by using an emulator. Of course real hardware is best because of accuracy. This would be perfect to prove it and also show others who want to use the same idea in their games.

I'll see what I can think up. The trouble with doing it at "small scale" is that's usually when you can get around the problem easier, but I'm sure I can dream up something....

[TFM]

Well, as long as everything fits into 64 KB there will be no problems. So small scaly doesn't really make sense. Problems begin with big productions. Usually at the moment when you start using Expansion RAM. In this case Cartridge ROM is just more flexible (of course w/o self modifying code).

[arnoldemu]

Well, as long as everything fits into 64 KB there will be no problems. So small scaly doesn't really make sense. Problems begin with big productions. Usually at the moment when you start using Expansion RAM. In this case Cartridge ROM is just more flexible (of course w/o self modifying code).

I think make a small example (i.e. shows one effect) but make it show that well, e.g. many sprites. Then you can compare side by side and just say: "It's better to use cart because ..... and you can see for yourself why"

[arnoldemu]

That hits the nail on the head for me - despite the lack of plus games available invite no the creation of new ones would be fantastic, I'd love a go myself - I've done C64 and CPC stuff but would love a chance to do some plus stuff without restriction.

Why restriction?

You can investigate the plus now - there is nothing to stop you doing that.

You can look at both disk and cart versions and as you discover things share them as we do.

I am sure that if there is a problem we can all solve it.

Try it on all the emulators that can do plus, try it on real machine, even if you have to make a piece of test code that runs from disk.

You can always ask others here who can put games onto REAL cart to test it for you.

I don't see any reasons not to try.

EDIT: Oh, do you mean restriction in terms of not using the cart? Well you don't need cart to stop you programming for plus and investigating the sprites, hardware scrolling etc.

[TFM]

Hey but SORRY!


We're getting really off topic now. Can we talk about making a muti Catridge for the Plus please (make another thread for Cartridge vs. Disc philosophy please).


Maybe somebody could split this thread into two:
- Multi Cart
- Cart vs. Disc

[arnoldemu]

Yes please split the topic. @Gryzor?

[Gryzor]

Not sure which posts to split, really... one, two posts maybe?