Mega Games Cartridge for the Electron MGC

[gebes]

Hi David

Thanks for checking for me, it's much appreciated indeed.

[daveejhitchins]

It may be possible to use a third 16K block! Let me ponder . . . It would mean your loader would need to know that it needed to switch-in the third block, and do this from outside of the cartridge - a bit like the dual 16K ROM (in one socket) with PLD switching! The block number would need to be held somewhere . . .

Dave H

[davidb]

I considered adding support for bank switching routines that are copied to RAM but the idea of hard-coding the bank numbers put me off. Either each ROM would know which bank comes next, or the routine could be generic and get the bank number from the paging register or the current ROM.

Then, of course, I'd need to copy images across to test on real hardware unless I modified Elkulator to support the paging mechanism that the MGC uses.

[daveejhitchins]

There's room in the index map, for each game, for locating further pages. This information would need to be loaded before the initial paging was carried out, however! Maybe the information could be stored in some unused location (0 page?), by the Menu program?

Dave H

[davidb]

I wasn't planning to add this for the current iteration of the cartridge, but for future reference this is how I'd do it.

The thing I'd want to avoid is having to tell the UEF2ROM tool about the bank numbers when the ROMs are created. This wouldn't be a problem if there was only one list (spreadsheet) of games, but allowing custom collections of games would mean that different ROMs would probably need to be produced for each collection. I would use a convention for placing related ROMs in adjacent banks (or some other predictable scheme) to make it possible for ROMs to determine which banks related ROMs are found in.

For example, in a four ROM set, each ROM could be numbered from 0 to 3 and get the bank number of the first ROM from a memory location (perhaps in zero page, but maybe from another unused location) then calculate their own bank number from those pieces of information. If we could read the paging register instead of using some byte in memory, that would be even better.

With two ROMs paged in at a time, each of the ROMs would need to include code to either page themselves out, or page out the other ROM. If this can't be done from ROM then a routine could be copied to RAM and run from there. The trigger for paging out ROMs could be added to the existing code for handling decompression.

[daveejhitchins]

You can already put games ROMs side by side and configure the cartridge to have just one of them showing at a time (there's no method, at the moment, to have two side-by-side games ROM's showing in the Cartridge!). You'll need to have code in main memory, to do the paging, so why not 'use' some main memory locations to store (placed my the Menu) the paging details which, as mentioned, can be stored in currently available locations in the Index ROM.

[davidb]

You can already put games ROMs side by side and configure the cartridge to have just one of them showing at a time (there's no method, at the moment, to have two side-by-side games ROM's showing in the Cartridge!). You'll need to have code in main memory, to do the paging, so why not 'use' some main memory locations to store (placed my the Menu) the paging details which, as mentioned, can be stored in currently available locations in the Index ROM.

Thinking about it some more, I would probably use the "one at a time" paging to switch out the second ROM, if possible. So the ROMs visible to the OS would look like this:

Code: Select all

ROM1 ROM2 (initial state)
ROM1 ROM2 (after reading ROM1)
ROM1 ROM3 (page in ROM3 after reading ROM2)
ROM1 ROM4 (page in ROM4 after reading ROM3)
...

What do you mean by having "two side-by-side games ROM's showing in the Cartridge"? Something like this?

Code: Select all

Game-1 Game-2 AnotherGame-1 AnotherGame-2

If that was possible then we wouldn't have to do any paging. It would be like having two 32K ROM cartridges plugged in. Have I misunderstood?

[daveejhitchins]

The MGC cartridge can be configured in one of two states. The default is for two ROM images to be visible, however, these are in different parts of the ROM e.g. At power-up or Ctrl/Brk, the visible 16K images are the bottom 16K and the 16K at the bottom of the second half of the ROM. With this version of MGC this can't be changed. The other configuration that the MGC can be placed into is for just one 16K image to be visible.

So, 16K blocks can be together in one of two ways. If the default conditions were to be used e.g. two 16K blocks visible, then if you need more than two 16K blocks, you only need one paging action - as when paged you get two new 16K blocks. e.g. the 2nd 16K, from the bottom address, and the 2nd 16K in the upper half of the ROM.

If you program the MGC to show just one 16K block, you would need a paging action for each 16K block you want to load. The 16K blocks could be together anywhere in the ROM space.

Dave H

[daveejhitchins]

At last . . . The first MGCs are ready to ship. I'll let people know as and when they are posted (from tomorrow).

Please feedback details of any games that do not work correctly. You'll receive the User Guide, once I get chance to write it! Also let me know what you think of the Usability e.g. is the Menu system fast enough?

Dave H

[richardtoohey]

That looks neat!

[davidb]

So, 16K blocks can be together in one of two ways. If the default conditions were to be used e.g. two 16K blocks visible, then if you need more than two 16K blocks, you only need one paging action - as when paged you get two new 16K blocks. e.g. the 2nd 16K, from the bottom address, and the 2nd 16K in the upper half of the ROM.

Ah, so it behaves as I expected. I just wondered if I'd missed something.

The finished cartridge looks good, by the way. Did you reuse old Acorn cartridge cases in the end?

[daveejhitchins]

Did you reuse old Acorn cartridge cases in the end?

I'm using what I can, including the 'expensive' one from Shapeways! I tried to use the black case that you sent me initially, however, the PCB won't fit due to the side location 'lugs' or the internal dimensions not being right. I have a number of Acorn cases that are being put to good use

On a different subject: Can we adopt a slightly different Game naming convention, please? As follows:

I'm only going to be listing the First file for any Game e.g. JungleJou1

I'll then let Richards php program know how many ROMs there are in the set e.g. for Jungle Journey it would be 2 with the second file being labeled JungleJou2 - any further files would be named following the sequence.

If it's a single file Game then the php will fit them in where it can. Two file Games are arranged with the first file in the lower half of the ROM and the second file in the upper half of the ROM (with the same numbered 16K block < necessary so that both are visible in the cartridge together).

For Games with more than two files we can add ten or twenty, to the the number of files, to indicate to the php program whether you want them side by side in the lower half of the ROM or paired as two file Games << e.g. three file games would have #1 file in the lower half of the ROM #2 file would be in the upper half of the ROM and #3 file would be in the lower ROM half just above the #1 file etc. etc.

None of this needs implementing straight away - as we don't have any three file Games, as yet!

Another request: Will the Haley Games be suitable for the MGC?

Dave H

[davidb]

If it's a single file Game then the php will fit them in where it can. Two file Games are arranged with the first file in the lower half of the ROM and the second file in the upper half of the ROM (with the same numbered 16K block < necessary so that both are visible in the cartridge together).

So, would I still number the single file games? For example, would Croaker.rom become Croaker1 instead, even though there's no Croaker2 file?

Another request: Will the Haley Games be suitable for the MGC?

In theory it would be possible if the paging tricks can be made to work. It depends on how large they are. Given that they were released on disk, the total size of the files could be huge. We'll see.

Looking at Dreamtime, it reads various files off the disk in a certain order, so that also has to be established before it can be made to work.

[davidb]

Dreamtime also opens multiple files for reading using OPENIN. While DFS seems to be happy with this, it doesn't look like either the TAPE or ROM filing systems allow this. Somebody please feel free to correct me if I'm wrong.

[daveejhitchins]

So, would I still number the single file games? For example, would Croaker.rom become Croaker1 instead, even though there's no Croaker2 file?

It wouldn't matter how single Games are named.

Looking at Dreamtime, it reads various files off the disk in a certain order, so that also has to be established before it can be made to work.

Well . . . I suppose we can't have everything - Maybe someone can come-up with some ideas for this type of game. We also need a solution for saving Game Positions - more thought!

Dave H

[paulb]

Did you reuse old Acorn cartridge cases in the end?

I'm using what I can, including the 'expensive' one from Shapeways! I tried to use the black case that you sent me initially, however, the PCB won't fit due to the side location 'lugs' or the internal dimensions not being right. I have a number of Acorn cases that are being put to good use

By the way, I recently uploaded the modified design with space for components on the back-facing side of the circuit board:

https://www.shapeways.com/product/SM4UG ... -cartridge

Click on the third picture to see the stupidly-animated version that might conceivably be paused to show the gaps in the board support struts. This modification should allow the battery-backed RAM board to fit. The sources for this model are in the usual place:

http://hgweb.boddie.org.uk/AcornElectro ... 5f2c2b6ce4

Shapeways now supports old-school PLA printing, but unlike the previous version of the model (without the gaps), the current version doesn't pass their validation tests: it's a wall thickness issue that I can't debug because their site wants the planets to be in complete alignment for my browser to support WebGL, but the uploaded model isn't supposed to be the easy-to-print version anyway.

[davidb]

So, would I still number the single file games? For example, would Croaker.rom become Croaker1 instead, even though there's no Croaker2 file?

It wouldn't matter how single Games are named.

Do you want me to send you a redone set of ROMs with the new naming scheme?

[daveejhitchins]

Do you want me to send you a redone set of ROMs with the new naming scheme?

Oh no, no , no . . . I can do this. Just wanted to set the scene for possible future three/four file Games.

Dave H

[Garrettimus]

Hi, Dave! Cool product!

I'd like to buy one, please...

[daveejhitchins]

Marcus . . . Added to the list.

Dave H

[Garrettimus]

Marcus . . . Added to the list.

Dave H

Thank you very much!

[jgharston]

Dreamtime also opens multiple files for reading using OPENIN. While DFS seems to be happy with this, it doesn't look like either the TAPE or ROM filing systems allow this. Somebody please feel free to correct me if I'm wrong.

CFS and RFS only allow one input file to be open at any time. CFS allows exactly one file to be open for output. DFS allows up to five files to be open (HADFS 5, ADFS 8, NFS 8 (including up to 3 context handles for @ % &) ANFS 16 (including up to 3 context handles). See the wiki.

[davidb]

Thanks for the information, Jonathan. I feared it might be the case that there would be a strict limitation on file handles for CFS and RFS. This means that many Heyley titles are unlikely to work unless they are "fixed" in some way. I'm slightly surprised that I haven't hit this limitation before now - or maybe I have, but just gave up on whatever game it was that failed to work properly.

[Garrettimus]

I'm having a tough time trying to remove games from the list... LOL!

Any suggestions of games to remove? So far I removed text adventures only... The truth is I'm not that familiarized with Electron games!

[davidb]

Maybe take a look at the Essential Electron games I should own... thread. Not all of those are available on the MGC, but many of them are.

[Garrettimus]

Maybe take a look at the Essential Electron games I should own... thread. Not all of those are available on the MGC, but many of them are.

Thank you, I'll have a look, David!

[dixiestoat]

My MGC arrived yesterday.
Its fab..!
172 games to go at. All with almost-instant loading.

When you grew up with a basic tape loading Elk BITD, all this new stuff the old girl can do just makes me laugh out loud.

I would have loved this 25 odd years ago.
Dave, Thankyou and Well done.

AP5 next please....? !
Nick.

[1024MAK]

A Mega Games Cartridge for the Electron arrived today

Thanks Dave H.

Yes, I had trouble making my selection. It took a while to work my way through the list.

Mark

[Garrettimus]

A Mega Games Cartridge for the Electron arrived today

Thanks Dave H.

Yes, I had trouble making my selection. It took a while to work my way through the list.

Mark

Fantastic! Congratulations! Can't wait to receive mine!

[Multiwizard]

A Mega Games Cartridge for the Electron arrived today

Thanks Dave H.

Yes, I had trouble making my selection. It took a while to work my way through the list.

Mark

Fantastic! Congratulations! Can't wait to receive mine!

Ditto...