Seems odd that, as far as I can see, nobody to date has produced a GX4000 multicast that could access images from an SD card.
So what gives? Isn't it possible or is the market too small?
I'd buy 3 tomorrow if it were available. One for each of my plusses.
Quote from: CraigsBar on 15:53, 18 October 14
I'd buy 3 tomorrow if it were available. One for each of my plusses.
Both my Atari 8 bit and my C64 have mass storage in their cartridge slots. The only thing I can think of is either the Plus/GX4000 market is too small or the implementation of the cartridge ports are different.
This is the 4th or 5th time someone brings this up.
Please do a search to find out all the reasons why it hasn't been done yet. It has been answered many times.
Cart shells, acids and the availability of an os to select the cart image on itself. we know. It'd still be good tho. Especially since with a x-mem you can boot a plus to basic even with a game cart in the slot. When my 464 plus comes back from Bryce I think I'll put my acid inside board in it, and see if that will boot from the xmem with no cart.
Quote from: mr_lou on 16:04, 18 October 14
This is the 4th or 5th time someone brings this up.
Please do a search to find out all the reasons why it hasn't been done yet. It has been answered many times.
If we put a ban on discussing old things we may as well have the forum closed down!
Quote from: chinnyhill10 on 16:14, 18 October 14
If we put a ban on discussing old things we may as well have the forum closed down!
Cart shells aren't a problem for other systems. They simply get new ones made.
Surely the ACID chip could be emulated as part of an FPGA that holds the carts firmware.
Certainly the 1541 Ultimate for the C64 and the Side2 for the Atari are basically computing devices in their own right that simply feed the 8 bit machines with the data they require.
Quote from: chinnyhill10 on 16:14, 18 October 14If we put a ban on discussing old things we may as well have the forum closed down!
It's not old. It's quite recent.
And the search button is there for a reason: To not have people repeat themselves answering the same question over and over again. ;)
Quote from: chinnyhill10 on 15:21, 18 October 14
Seems odd that, as far as I can see, nobody to date has produced a GX4000 multicast that could access images from an SD card.
So what gives? Isn't it possible or is the market too small?
The problem isn't the market, more the available software. There's less than 30 titles available on cartridge, so an SD card is total overkill, they'd fit on a simple EPROM with some DIP switches.
Bryce.
Honestly, If I had the spare money and equipment, I'd develop one in a heartbeat. However, without the ROM for Chase HQ2, it would be incomplete. :(
Quote from: Novabug on 19:33, 18 October 14
Honestly, If I had the spare money and equipment, I'd develop one in a heartbeat. However, without the ROM for Chase HQ2, it would be incomplete. :(
The C64 and Atari don't have that many cartridge titles but their solutions not only let you load carts, but any software you like.
OK a device like the 1541 Ultimate is high end and expensive, but it will load everything you throw at it. Disk images, tape images and all from the cartridge slot.
Quote from: mr_lou on 16:26, 18 October 14
It's not old. It's quite recent.
And the search button is there for a reason: To not have people repeat themselves answering the same question over and over again. ;)
I don't see a problem, it promotes the idea that this is a friendly and helpful site, if it really is a problem then a FAQ stickied thread could hold the answers to those questions, then again maybe all frequently asked questions need their own wiki pages.
vicious circle debate...
No Hardware = no one to develop Software for this.
No software = no one to develop the hardware.
To arrange production for casing and perhaps 500-1000 empty cartriges first batch would need a few thouzand euros in advance and no one kickstarted this yet..
issue is that when we talk about it, some want a Man in the Middle solution so you need only one ACID chip, other want an emulated ACID on each cartridge, other want the cartridge to be actually a developper kit with easy possibility to burn the ROM directly from the cartridge slot (which is impossible lol), others want a 4x128K compilation model and other want a 512K model. Some suggest EEPROM others suggest FlashROM. some want a simple classic cartridge while other want it to be an SD card reader.
And people are never never never aggreeing on the colur for the casing.
and yep, every 6 month someone new start this exact same thread, but this is not a problem to me. ;D
I see the debate is repeating itself.
Here are some links where you can read ahead then, and see what questions will be asked and what the reply will be.
"Everdrive" cartridge for GX4000 (http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/%27everdrive%27-cartridge-for-gx4000/)
Idea! A CPC+/GX4000 Cartridge Emulator? (http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/idea!-a-cpcgx4000-cartridge-emulator/)
Existing games => Cartridges (http://www.cpcwiki.eu/forum/games/existing-games-gt-cartridges/)
New Plus Series Game a Proposal (http://www.cpcwiki.eu/forum/games/new-plus-series-game-a-proposal/)
CPC cartridges possible to make new ones or not worthwhile? (http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/cpc-cartridges-possible-to-make-new-ones-or-not-worthwhile/)
I brought it up myself previously because I'd love to see a multicartridge for my CPC+
So much that I'm willing to donate at least 100 euro to the project.
But the experts have spoken (many times), and it doesn't seem to be happening.
What I suggested last time is this: Everyone agree on what the best option is. Then start a fundrazr or kickstarter or whatever, and then just get started.
But there are many issues not yet resolved, e.g. about creating the cases. 3d printing vs molding. Lots of opinions about what is best. And we're not getting anywhere closer to an agreement.
Personally, I'd love a cartridge like the Everdrive, that takes an SD card. That opens up for more potential CPC+ developers too, since it'll be easy to test their CPC+/GX4000 games on the real device. And I'd love to see new cartridge games for my CPC+, that uses much more of the CPC+ features.
But everyone is right about what they say: The current amount of games just isn't worth making such a multicartridge for. The creation of plastic cases is crazy expensive. ACID ship expensive to emulate. Everything is possible, but requires money, moeny and time and money and time.
Let's put it another way: Let's see the money first. Someone (that we agree should do it) should create this fundrazr, or simply just receive donations via paypal, and then we'll see where we stand.
Get it started already! :)
i already see a crook going out with our money and no cartridges done... :laugh:
(http://genophoria.files.wordpress.com/2012/11/shut-up-and-take-my-money.jpg)
Shut up and take my money !!!
Quote from: MacDeath on 08:47, 19 October 14
i already see a crook going out with our money and no cartridges done... :laugh:
I doubt we'll ever reach the fundraiser stage.
As you say yourself, we'll never ever agree on which way to go.
I don't see it ever happening.
All we'll see are new threads every now and then, people asking all over why we don't have it yet.
If you're not prepared to donate at least 100 euro to this project, then you're not interested enough, and then it will never happen. Talk all you will. Won't produce any cartridges. ;)
Quote from: chinnyhill10 on 23:47, 18 October 14
The C64 and Atari don't have that many cartridge titles but their solutions not only let you load carts, but any software you like.
OK a device like the 1541 Ultimate is high end and expensive, but it will load everything you throw at it. Disk images, tape images and all from the cartridge slot.
The C64 had over 300 software cartridges, the Atari 8-bit series had around 150, the CPC had 26.
Bryce.
Quote from: Bryce on 13:17, 19 October 14
The C64 had over 300 software cartridges, the Atari 8-bit series had around 150, the CPC had 26.
Bryce.
Are you including the homebrew carts and my conversions?
Which includes:
Blue Angel 69
Stryker and the Crypts of Trojan.
It would take me a while to get to 300! ;)
Quote from: arnoldemu on 15:54, 19 October 14
Are you including the homebrew carts and my conversions?
It would take me a while to get to 300! ;)
...but you can do it!
We're depending on you! :)
Quote from: arnoldemu on 15:54, 19 October 14
Are you including the homebrew carts and my conversions?
Which includes:
Blue Angel 69
Stryker and the Crypts of Trojan.
It would take me a while to get to 300! ;)
you converted Stryker to cart? Is it gx4000 friendly? Did you add any thing extra or just port from the dsk?
Craig
Quote from: CraigsBar on 17:14, 19 October 14
you converted Stryker to cart? Is it gx4000 friendly? Did you add any thing extra or just port from the dsk?
Craig
Yes I did either earlier this year or a year ago.
Yes it's gx4000 friendly. :)
I took the disk version and converted it to cart using my filesystem. I used the disk version but I did modify it.
Cart will use 128k if found to get the extras you get on the 128k version.
I modified the code so that you can start the game by pressing fire and if you do P is the pause button (to map to the gx4000 pause button). The title screen shows, you can press fire to skip it or leave it for 30 seconds and it goes on it's own and into the game.
I didn't make any changes to the graphics, sound or gameplay.
Quote from: arnoldemu on 15:54, 19 October 14
Are you including the homebrew carts and my conversions?
Which includes:
Blue Angel 69
Stryker and the Crypts of Trojan.
It would take me a while to get to 300! ;)
No, just the original list from the Wiki.
Bryce.
Just out of interest the "Unable to code the cartridge from the CPC" might be resolved. I have just sucessfully booted my 6128plus with no cartridge at all... How is this black magic achieved I hear you say....
Ok Here it is...
First I have one of Bryces Acid Inside boards in my 6128plus.
Second I have an X-MEM with FW3.15 and switched to boot from the x-mem firmware
when the machine is powered on with no cartridge the FW boots (Although clearly no disc commands work) ROM software works just fine - Tested with Protext, FutureOS, Chuckie Egg and 1942.
So If I can boot the machine and run ROM software without an issue with no cart installed. So long as the flash cart has a ACID in it, with an X-MEM you can obviously run a CPC plus with no cart at all.
Now here comes the problem. TO achieve maximum target audience, this device would need to also work on a GX4000 and as such it needs to work without any intervention from the machine (Or require an xmem to reprogram it)
Therefore Personally I think a microSD card 'Cartridge Emulator' type solution would be the way to go. Provide it with a full OS that can copy CPR images from an inserted SD card to its own emulated ROM.
A boot menu for access this OS or boot the current emulated ROM like the Plus Burning Rubber menu (Although obviously using joypad A and B rather than F1/F2) this way the dev's could use it as a programming tool. Users of all plus machines including the GX4000 couls use it to play 25 out of 26 official commercial games and everyone would be happy?
Sure this solution would cost more than a more basic cart, and I am sure the hardware and software guys will tell me a million reasons why none of this is possible but I would gladly hand over 100 hard earned euros (or More if it came with a nice shell/case) for such a device.
I realise that all of this would require a pretty damn intelligent cartridge with some built in CPU and file management tools. But impossible - I hope not.
After all I live in hope that one day we will gat this, and the day after one of those famous 2 Chase HQ2 carts will get dumped to CPR.
Craig
Essentially we're looking at a CPC equivalent of the 1541 Ultimate which is a highly specced cart for the C64 which costs approx 120 Euros.
http://www.1541ultimate.net/content/index.php?option=com_content&view=featured&Itemid=127 (http://www.1541ultimate.net/content/index.php?option=com_content&view=featured&Itemid=127)
This is what I have for my Atari which is the My IDE (not the Side 2 as I said earlier). It's 70 US dollars:
Atarimax MyIDE-II Compact Flash Cartridge for Atari XL/XE Computers (http://atarimax.com/myide/documentation/)
Much cheaper. Cart case not as nice as the 1541 Ultimate but you do get a choice of colours and like the 1541 Ultimate it's a pretty powerful device.
Quote from: chinnyhill10 on 20:32, 19 October 14Essentially we're looking at a CPC equivalent of the 1541 Ultimate which is a highly specced cart for the C64 which costs approx 120 Euros.
No, that's not what we're looking at.
The 1541 Ultimate is not a cartridge-emulator / multicartridge. It is more like a 1541 drive emulator. It doesn't contain cartridge images. It contains disk (d64) images.
The CPC has the HxC for this.
What we want is more like a CPC equivalent of the C64 Easy Flash cartridge.
EasyFlash 3 - RETRO Innovations (http://store.go4retro.com/easyflash-3/)
But in a version that allows storage of CPR files on SD card.
Quote from: CraigsBar on 19:50, 19 October 14
After all I live in hope that one day we will gat this, and the day after one of those famous 2 Chase HQ2 carts will get dumped to CPR.
Given what you said earlier about booting a Plus from X-Mem with a game cart inserted, I can't see this being much of a problem. Just install AMSDOS/ParaDOS in the X-Mem and copy the cart banks using a simple bit of code.
Quote from: Executioner on 06:14, 20 October 14
Given what you said earlier about booting a Plus from X-Mem with a game cart inserted, I can't see this being much of a problem. Just install AMSDOS/ParaDOS in the X-Mem and copy the cart banks using a simple bit of code.
hmm. Well kinda. With no cart inserted it runs just fine. As the xmem does not replace Rom 7(cart slot 3) then with a game cart in the slot it hangs trying to initialize what I guess is effectively garbage data in what it thinks is slot 3 / rom 7. Perhaps a mother x4 board to provide a smaller flash to replace Rom 7 on a switchable basis is the solution here as well.
Quote from: CraigsBar on 07:56, 20 October 14
hmm. Well kinda. With no cart inserted it runs just fine. As the xmem does not replace Rom 7(cart slot 3) then with a game cart in the slot it hangs trying to initialize what I guess is effectively garbage data in what it thinks is slot 3 / rom 7. Perhaps a mother x4 board to provide a smaller flash to replace Rom 7 on a switchable basis is the solution here as well.
464+ or 6128+?
EDIT: Ah yes, I see what you mean now. Bit slow this morning.
If the x-mem's base could be moved to 128 then it could be a replacement for cart somehow?
My two cents on the discussion:
Yes, it has been discussed before. Yes, quasi-definite answers were given.
...and NO, I don't think a "use the search function" reply is appropriate. It's not friendly and, frankly, is out of place here. It gives a bad image of the community. It's one thing trying to, say, give a complex technical answer that has been given already and another having a general discussion. Heck, we've had countless questions about drive pins before, and we always answer them, people! What's wrong with giving some pointers (as has been done numerous times in the past) to previous threads instead of being uptight?
Not only that, but in many cases (this one included) regurgitating an existing issue can lead to new answers and renewed interest. So, let's all be friendly and accommodating.
[/rant]
@chinnyhill10 (http://www.cpcwiki.eu/forum/index.php?action=profile;u=984) : to sum it all:
-the ACID issue. To use an FPGA would probably raise the cost too much.
-the casing issue. No solution found up to now though some people are trying their hand at it. Community/interest too small to support moulding for new cases
-no titles worth the trouble. Launch disk images etc? Why, we have the HxC for that.
Not that people wouldn't be interested in one. I'd certainly get one or two (and I'm hoping someone is secretly working on one). But the combination of factors has put a multicart aside...
Any chance that your rant was actually meant for this thread? Wiki search box (http://www.cpcwiki.eu/forum/cpcwiki-discussion/wiki-search-box/msg87758/#new) :)
Bryce.
Upvoting for cynicism points :p
Quote from: arnoldemu on 08:53, 20 October 14If the x-mem's base could be moved to 128 then it could be a replacement for cart somehow?
Originally, it was 128 based bootable range but peoples asked to be a standard ROM board.
8)
Quote from: Gryzor on 13:32, 20 October 14
...and NO, I don't think a "use the search function" reply is appropriate. It's not friendly and, frankly, is out of place here. It gives a bad image of the community. It's one thing trying to, say, give a complex technical answer that has been given already and another having a general discussion. Heck, we've had countless questions about drive pins before, and we always answer them, people! What's wrong with giving some pointers (as has been done numerous times in the past) to previous threads instead of being uptight?
This was what I wrote:
Quote from: mr_lou on 16:04, 18 October 14
This is the 4th or 5th time someone brings this up.
Please do a search to find out all the reasons why it hasn't been done yet. It has been answered many times.
Considering the many previous in-appropriate and rude replies I have received here in the past, I'm somewhat disappointed that my non-rude reply causes you to write a rant like that, when nothing even close has been posted when people has been rude to me. I wasn't being rude here.
Ok, we're coming close to a flame war... time for me to jump in: :laugh:
What would a Multi-Cart need?
- SD card for enough space for current & future games
- OS caring about Cart selection
- ACID replacement!?
Solution:
- SD cards are now usable, see HxC and other solutions
- OS: Use the Cart Player from Amstrad, else I'm sure Prodatron will make a SymbOS version for it. (Maybe even I consider doing a special version of FutureOS for cart management).
- ACID: Just take the ACID inside solution. OR the man in the middle solution, Bryce showed that before.
And no, we don't need the super-duper-Alice-Cooper-all-original cartridge shell. We can just take one that fits.
Ok, ordering two pieces of that hardware now ;)
Personally I don't see the SD Card as necessary for it's storage capacity, but rather that it's more likely to be an easier solution to the problem of "How do we get files from a PC/Mac onto the cart?" And the extra capacity can always be put to use to simplify the design if needed (for example rather than complex logic to parse and map different sized carts, we just store 512K images with duplicate pages as needed).
Cart selection is a trickier issue, I don't know whether it would be technically easier to use something along the lines of an external hardware solution (like the screen+buttons on an HxC) or whether it could be an entirely software based solution, which might be trickier given the limited capabilities of the cart slot.
Quote from: mr_lou on 06:03, 20 October 14
No, that's not what we're looking at.
The 1541 Ultimate is not a cartridge-emulator / multicartridge. It is more like a 1541 drive emulator. It doesn't contain cartridge images. It contains disk (d64) images.
Incorrect.
The 1541 Ultimate can emulate a 1541, can also load T64 files (tape files), a number of other formats and "C64 Cartridge Emulation" including Ocean and System 3 custom ROM's.
It is much much more than a mere floppy drive emulator. In CPC terms it's a HxC, Multiface and a cart emulator all in one.
Quote from: Gryzor on 13:32, 20 October 14
@chinnyhill10 (http://www.cpcwiki.eu/forum/index.php?action=profile;u=984) : to sum it all:
-the ACID issue. To use an FPGA would probably raise the cost too much.
-the casing issue. No solution found up to now though some people are trying their hand at it. Community/interest too small to support moulding for new cases
-no titles worth the trouble. Launch disk images etc? Why, we have the HxC for that.
Not that people wouldn't be interested in one. I'd certainly get one or two (and I'm hoping someone is secretly working on one). But the combination of factors has put a multicart aside...
I know the 1541 Ultimate guy had to pay a high cost for his (rather lovely) carts. But the Atari guys have gone for something much cheaper and it still works. 3D printing might also make it even more accessible in a few years.
I'm wondering if a multicart isn't possible if the GX4000 exclusive titles could be hacked to work from floppy. A difficult project perhaps but one that would let Plus owners use an HxC to play rare/overpriced games.
Quote from: chinnyhill10 on 22:00, 20 October 14The 1541 Ultimate can emulate a 1541, can also load T64 files (tape files), a number of other formats and "C64 Cartridge Emulation" including Ocean and System 3 custom ROM's.
It is much much more than a mere floppy drive emulator. In CPC terms it's a HxC, Multiface and a cart emulator all in one.
I stand corrected. Didn't know it also ran cartridge files.
I still don't think we're looking for a CPC equivalent of the 1541 Ultimate though. Sure, it would be awesome if it was possible, but I doubt that a lot.
I still think what we're looking for, is a CPC equivalent of the Easy Flash 3 for the C64.
In any case, at this point I'd be happy for just about anything produced in this category for the CPC.
@mr_lou (http://www.cpcwiki.eu/forum/index.php?action=profile;u=96) : it's not (only) about rudeness, it's about how the forum and discussions function, too. But if I've missed any rudeness towards you, please feel free to report the posts.
@TFM (http://www.cpcwiki.eu/forum/index.php?action=profile;u=179) : so it's a storage thing that also has the ability to load cartridges. Sure, that'd be lovely, but a multicart is quite limited in its functionality. Also, good luck finding cartridge shells that fit :(
How about we reverse the problem. Perhaps an easier approach (or at least cheaper one) is to try and transfer the cartridges to disk. I suspect in all but the simplest of games this could be reasonably complex since disk loading routines would need to be built etc. space might not be a problem if we use the higher capacity of 3.5" drives and Parados.
Just a thought...
Quote from: endangermice on 12:50, 21 October 14
How about we reverse the problem. Perhaps an easier approach (or at least cheaper one) is to try and transfer the cartridges to disk. I suspect in all but the simplest of games this could be reasonably complex since disk loading routines would need to be built etc. space might not be a problem if we use the higher capacity of 3.5" drives and Parados.
Just a thought...
again a good idea, but I think in parallel to an sd cart or new carts. Simply because gx4000 users cannot use discs.
Quote from: endangermice on 12:50, 21 October 14
How about we reverse the problem. Perhaps an easier approach (or at least cheaper one) is to try and transfer the cartridges to disk. I suspect in all but the simplest of games this could be reasonably complex since disk loading routines would need to be built etc. space might not be a problem if we use the higher capacity of 3.5" drives and Parados.
Just a thought...
I can't tell you how easy/hard that would be.
Storage space is not the problem. The problem is how much patching to the game it would need to make it work from disc.
That's exactly what I was thinking, patching could be difficult. I need to read up more on this wiki on how the cartridge system works but I guess there's a series of addresses into which cartridge data is made available - perhaps even the full 64kb memory space. Somehow that data is swapped around for larger carts which is obviously a heck of a lot easier (and quicker) with solid state than disk.
It would be nice to see more plus games, but it's already been proved that it's perfectly possible to make them available on disk. That does unfotunately preclude GX4000 users. I think one of the problems is that the Amstrad disk system is (especially when compared to machines like the c64) damned fast which makes the presence of a cartridge format less desirable than perhaps other systems since the drive emulation isn't exactly a slouch either.
Quote from: endangermice on 12:50, 21 October 14
How about we reverse the problem. Perhaps an easier approach (or at least cheaper one) is to try and transfer the cartridges to disk. ...
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.
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!).
Doesn't a cartridge game offer huge advantages over a disk game?
Please don't tell me we want new cartridge games just because they load faster.
I'd expect some kind of not-seen-before result.
Quote from: endangermice on 13:31, 21 October 14
It would be nice to see more plus games, but it's already been proved that it's perfectly possible to make them available on disk. That does unfotunately preclude GX4000 users. I think one of the problems is that the Amstrad disk system is (especially when compared to machines like the c64) damned fast which makes the presence of a cartridge format less desirable than perhaps other systems since the drive emulation isn't exactly a slouch either.
I've said it before, but if you actually try to write code for the Plus machines that pushes the hardware it becomes abundantly obvious that it would be easier if you can run from cart. 64K is not nearly enough and the RAM banking scheme of the 6128+ is incredibly cumbersome as it "gets in the way" of the ASIC registers. You have to do a fair bit of juggling around to make effective use of the system in a way that you can simply sidestep with the dual ROM mapping schemes.
Quote from: mr_lou on 19:01, 21 October 14
Doesn't a cartridge game offer huge advantages over a disk game?
Please don't tell me we want new cartridge games just because they load faster.
I'd expect some kind of not-seen-before result.
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.
I haven't investigated exactly what benefit it gives. If someone else can give real world answers with speed comparisons and explain exactly how it benefits it would be great to share it with everyone.
What it can give us is games closer to the console experience if they are made to use joypad only. Then it becomes instant start, no pauses during play, benefits of 128k on all plus systems including gx4000, works from joypad playable at a distance on a big screen.
Has anyone got any code examples they can share which can be run on a real device which shows how cart is better if used well?
I can't claim cart is best because I haven't tested it to prove it for the best or not.
Quote from: andycadley on 19:02, 21 October 14
I've said it before, but if you actually try to write code for the Plus machines that pushes the hardware it becomes abundantly obvious that it would be easier if you can run from cart. 64K is not nearly enough and the RAM banking scheme of the 6128+ is incredibly cumbersome as it "gets in the way" of the ASIC registers. You have to do a fair bit of juggling around to make effective use of the system in a way that you can simply sidestep with the dual ROM mapping schemes.
Any code examples to justify your claim?
The good cart games are like console games. Good presentation with company logo, title screen, screen fades, many tunes, good graphics with good use of colour, no load delays, playable by joypad alone, no menus, pang has a game attract sequence with demo, many cycle through different screens when left for a time. You get more like this because of the instant load. On disk you could have identical but with load times as it switches between screens. Instant loading is a positive thing and opens up more enjoyable play.
Quote[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.
Quote from: arnoldemu on 19:23, 21 October 14
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.
Quote from: TFM on 21:43, 21 October 14
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.
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.
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.
Quote from: arnoldemu on 09:52, 22 October 14
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!).
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.
Sorry , I think tapatalk had a Fritz for a minute. Now how to delete the 3 dupes.
Gryzor deleted the delete feature (suxx!). So you can change them but not delete them. Just post a nice picture. :)
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.
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?
Quote from: arnoldemu on 17:45, 22 October 14
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.
Quote from: CraigsBar on 17:50, 22 October 14
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.
Quote from: andycadley on 19:41, 22 October 14
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
Quote from: CraigsBar on 17:53, 22 October 14
Sorry , I think tapatalk had a Fritz for a minute. Now how to delete the 3 dupes.
Removed.
Bryce.
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.
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...).
QuoteI'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.
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 ;)
Quote from: arnoldemu on 19:57, 22 October 14
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....
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).
Quote from: TFM on 21:53, 22 October 14
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"
Quote from: endangermice on 20:53, 22 October 14
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.
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
Yes please split the topic. @Gryzor (http://www.cpcwiki.eu/forum/index.php?action=profile;u=1)?
Not sure which posts to split, really... one, two posts maybe?
Quote from: Gryzor on 18:49, 27 October 14
Not sure which posts to split, really... one, two posts maybe?
The two subjects are a bit interleaved, probably easier just to start a completely new Cart vs Disk thread with a link from this thread.
Bryce.
2nd that.
Tend to agree...
I am curious though, if I want to do the EEPROM replace thing, how easy it is? I have no experience with electronics. But I have used soldering tool in the past. What additional tools will I need? A tube to suck the melting thing I guess? And the EEPROM base. I could start now but I am a bit scared, hehe :)
I bought 3 more additional Burning Rubber cartidges just for this one. My interest is for the GX4000 and to not have to buy any more the expensive games (even though I own a good collection now, not many are missing). Maybe later I will try to port Flappy UFO on the GX4000 just for my own enjoyment of running something of my own on this console :)
p.s. Also do I need to get a specific EEPROM with specific pins I guess?
Quote from: Optimus on 11:15, 28 October 14
I am curious though, if I want to do the EEPROM replace thing, how easy it is? I have no experience with electronics. But I have used soldering tool in the past. What additional tools will I need? A tube to suck the melting thing I guess? And the EEPROM base. I could start now but I am a bit scared, hehe :)
I bought 3 more additional Burning Rubber cartidges just for this one. My interest is for the GX4000 and to not have to buy any more the expensive games (even though I own a good collection now, not many are missing). Maybe later I will try to port Flappy UFO on the GX4000 just for my own enjoyment of running something of my own on this console :)
p.s. Also do I need to get a specific EEPROM with specific pins I guess?
Someone like ikonsgr can probably help you out. He's in Greece too which will save you the postage. Desoldering a Cart if you've never soldered before has about an 80% chance that you damage the ACID or PCB in the process.
Most EEPROMs have the same pinout as the equivalent EPROM (except the 400Mbit ones).
Bryce.
Does anybody have an open cartridge at hand to provide some size measurements?
-width
-height
-thickness (presumably 1.6mm)
-location of the bottleneck (where the contacts are)
-location of the mounting hole on the pcb
-pitch of the contact-pads
thanks!
Take a look at the pictures here: GX4000 cartridge - CPCWiki (http://www.cpcwiki.eu/index.php/Cartridge#Pictures) The pins of the EPROM and ACID are the standard 2.54mm, you can calculate the rest from that. Or alternatively you can download and print out the Layout file of the MultiCart: Multi Cartridge - CPCWiki (http://www.cpcwiki.eu/index.php/Multi_Cartridge) and measure it manually.
Bryce.
What can I say --- simply beautiful.
THANKS again.
we'll see where this is might be leading to.... ;-)
(https://lh5.googleusercontent.com/-IfAZY8drQ04/VE_UHY5IBmI/AAAAAAAAJ0o/vp0YxMUFlt0/s800/downloadfile.png)
(https://picasaweb.google.com/115948745418514736250/GX4000#6075307645752313442)
What's the maximum size that a gx4000 can handle?
would a 32mbit flash exceed its limits?
I'd like to drop the usb-port and concentrate on one single ic which holds all games plus the menu for selecting and bankswitching.
I have a AM29F032B on my pcb layout right now but someone pointed out that the gx4000 might eventually not be able to work with such a big thing.
Thanks!
Quote from: ArcadeTV on 00:15, 29 October 14
What's the maximum size that a gx4000 can handle?
would a 32mbit flash exceed its limits?
I'd like to drop the usb-port and concentrate on one single ic which holds all games plus the menu for selecting and bankswitching.
I have a AM29F032B on my pcb layout right now but someone pointed out that the gx4000 might eventually not be able to work with such a big thing.
Thanks!
Hi ArcadeTV,
I have already designed something very similar, but I never got around to building it. I'll send you a PM with some details / notes. And yes, there are ways for the CPC to handle a Flash that size.
Bryce.
I will meet Bryce to work this out.
I'm very positive that this will result in something very cool 8)
This is all work-in-progress. I'll report any progress when the time is right.
(https://lh5.googleusercontent.com/-bgtqD5s4jio/VFD6JBzURZI/AAAAAAAAJ1s/sojHlFkgUW0/s800/gx4000_wip.png)
This looks good. Is the flash reflashable? Or is it a program once externally thing?
I dunno yet - we'll see what we can work out.
Personally a programm-once-thing with all games on it would be very satisfying to me...
but if the flash can be made writable - ... - who knows.
I'll let the pro's decide ;-)
Just a tip for the Layout: Don't put ground-plane between the edge connector pads, it will cause havoc and possible short-circuits if the cartridge isn't perfectly aligned.
Bryce.
sure thing! also there are no caps yet. it's just the beginning to have something to work with. i'm already excited about it though.
Quote from: ArcadeTV on 00:15, 29 October 14
What's the maximum size that a gx4000 can handle?
Using the commercial Cartridge design the maximum amount its 512 KB, that can be set by the right jumpers (Loetbruecken) on the Cartridge PCB.
However you can go up to 2 MB of ROM. It will be addressed in 16 KB pieces by sending a byte to port &DFxx. Values can be from 128 to 255.
For a warmUp I recreated the cart pcb in Eagle as it is for use with eeproms and ACID. I added the "LK" jumpers as solder-pads.
I included the gerber-files to this post.
Please download the zip, extract it and go to webGerber (http://mayhewlabs.com/webGerber/)
Drag the files into the website and click OK on the next screen.
This should generate an interactive 3D-view of the PCB, you can play around with it using your mouse.
>>Please Note: the web-gerber-viewer has issues with the board's outlines! It will only display the rectangular shape of the pcb, of course the outlines are present and match the original pcb.
Alternatively go to Download Gerber Viewer Program (http://www.zofzpcb.com/Gerber_Viewer_Download.html) and download this great piece of software. Install it, launch it,
then go to top MENU >>
FILE > Compose New > Auto
browse to the folder where you extracted my gerber-files and click
AUTO LOAD
then
OK: Read & Render
Tipp: if select VIEW > Color Preset > Net Color Haven
then you could do me a big favor and check everything. Report if you find an issue!!
Thanks and have fun!
(https://lh5.googleusercontent.com/-v6ju_VYSHLA/VFJmwYRRkHI/AAAAAAAAJ30/4LBFmV5SmWY/s800/simple_gx_cart_v1_compside.jpg)
(https://lh4.googleusercontent.com/-KtBJ2yoL0ws/VFJmwUUkT1I/AAAAAAAAJ3w/hwXwVf2kBaQ/s800/simple_gx_cart_v1_solderside.jpg)
(https://lh5.googleusercontent.com/-KXYoOtrmgw4/VFJnQsg8TyI/AAAAAAAAJ4E/0ZwAJQdlonA/s800/gx_schematic.png)
Quote from: TFM on 17:13, 29 October 14
Using the commercial Cartridge design the maximum amount its 512 KB, that can be set by the right jumpers (Loetbruecken) on the Cartridge PCB.
However you can go up to 2 MB of ROM. It will be addressed in 16 KB pieces by sending a byte to port &DFxx. Values can be from 128 to 255.
There are other tricks available to allow limitless amounts of ROM / Flash on a cartridge. A 64MB cartridge wouldn't be a problem.
Bryce.
From what I've seen on the cart-pictures in the wiki, LK1 and LK6 seem to be pretty useless? Am I correct?
Quote from: Bryce on 17:00, 30 October 14
There are other tricks available to allow limitless amounts of ROM / Flash on a cartridge. A 64MB cartridge wouldn't be a problem.
Bryce.
Well, sounds like I have to give Maxam an intensive care this weekend, to produce at least a 64KB of something. :laugh:
The best idea would IMHO be to use a second port to select different ranges of 2 MB each. That could give up to 512 MB. :o :) :)
Quote from: ArcadeTV on 18:02, 30 October 14
From what I've seen on the cart-pictures in the wiki, LK1 and LK6 seem to be pretty useless? Am I correct?
LK1 sets the A18 pin of the EPROM to VCC - It needs to be VCC if a 27C1001 or 27C2001 is installed. But if a 27C4001 is installed it needs to be removed and LK2 needs to be set.
LK6 connects the CPC A15 to A15 of the EPROM, this also needs to be switchable, because if a 27C256 was installed, this EPROM pin needs to be connected to VCC.
In both cases, because the EPROM pin is the PGM pin on those EPROMs.
Bryce.
but if you look at the blank pcb in the wiki you'll find that the traces render the jumper useless :/ or am I mistaken?
Quote from: ArcadeTV on 22:29, 30 October 14
but if you look at the blank pcb in the wiki you'll find that the traces render the jumper useless :/ or am I mistaken?
Yes, there are some PCB layouts where it's not permanently wired, but many are, probably because Amstrad made some great deal to bulk buy 27C1001 or 27C2001 from some supplier and realised they could save another few cents because these jumpers would always need to be set. In reality you'll also notice, that in many cases a 27C2001 is installed although the game only used 128K.
Bryce.
ok.. thanks!!
could you have a look at my pcb and check if i made the right connections?
(beside the 2 missing jumpers)
I'd drop the jumpers completely and wire it for a 27C4001. The smaller ones are the same or more expensive these days. A 512K is cheaper than a 128K or 256K and easier to find.
Bryce.
so that would be the same wiring as in your multipcb, right?
Yeah, just without the DIP switches and the pull-up resistors.
Bryce.
Quote from: Bryce on 22:28, 30 October 14
LK1 sets the A18 pin of the EPROM to VCC - It needs to be VCC if a 27C1001 or 27C2001 is installed. But if a 27C4001 is installed it needs to be removed and LK2 needs to be set.
LK6 connects the CPC A15 to A15 of the EPROM, this also needs to be switchable, because if a 27C256 was installed, this EPROM pin needs to be connected to VCC.
In both cases, because the EPROM pin is the PGM pin on those EPROMs.
Now I'm totally confused :-( sorry...
In your multicart-pcb-layout A17 and A18 are not connected, but you said LK2 needs to be set if a 27C4001 is used...
Right now my 27C4001-pins 30/A17 and 31/A18 are connected to A17 and A18.
Is that correct?
(https://lh4.googleusercontent.com/-cZC-mPScAIM/VFPt2t7G09I/AAAAAAAAJ48/SWLicAO07MI/s800/gx_schematic.png)
My MuliCart only connects 128K to the CPC, the other Address bits are turned on/off manually to select which 128K block of the EPROM the CPC sees. You should connect these pins directly to the CPC to access the whole EPROM at once.
Bryce.
Gesendet von meinem Motorola DynaTEC 8000X mit Tapatalk 2.
Of course you saw Geralds other thread in which he actually presents a working Cartridge. So I would suggest to join forces with him instead of reinventing the wheel. :)
CPC Plus cartridge replacement : one more (http://www.cpcwiki.eu/forum/amstrad-cpc-hardware/cpc-plus-cartridge-replacement-one-more/)
It's not inventing the wheel twice. They are two different devices with different features and probably a different price range too.
Why not do both?
Bryce.
Gesendet von meinem Motorola DynaTEC 8000X mit Tapatalk 2.
Join forces. Make one of them.
Then join forces again, make the other.
But not both at the same time. :)
I speak for all us consumers when I say: We can't wait any longer! :)
Not my choice, it's ArcadeTVs project.
Bryce.
Gesendet von meinem Motorola DynaTEC 8000X mit Tapatalk 2.
This cartridge with multiple games sounds like a great idea, but it needs to either have a way of doing a reset back to one of a number of setup options (eg. BASIC, game selector, current game reset). Maybe even two BASIC configurations with/without ParaDOS 1.2+, or just two reset buttons (one to select the game/configuration and the other to reset the current config).
It'd be great if the game selector had the ability to modify parts of the EEPROM through disc/tape or some other means (especially for GX4000), then if any new cart software gets made it's easy to upgrade.
And don't forget the FutureOS autostart and the X-DDOS as Amsdos replacement. Ok, Varados too. ;)
Quote from: TFM on 23:35, 12 November 14
And don't forget the FutureOS autostart and the X-DDOS as Amsdos replacement. Ok, Varados too. ;)
That's a great reason to have it writable, so we can put custom OS etc in it.
Yes, writable from the CPC side. :)