Mega Games Cartridge for the Electron MGC

[daveejhitchins]

Plenty left, I managed to get hold of 80 FlashROMs so I ordered enough parts for them all. I think I'm up to 30+ , so far

Dave H

Please contact me next week, M Sadler . . .

[davidb]

Plenty left, I managed to get hold of 80 FlashROMs so I ordered enough parts for them all. I think I'm up to 30+ , so far

You don't believe in half measures, then?

[daveejhitchins]

In for a penny etc.

Dave H

[roland]

I have build a RGB to SCART cable today and tested mine. It works great! Good to see those old games again.
Unfortunately my Elk crashes after playing games for a while and I have unplug the power about five minutes and then it works again for about 10 minutes. But that's something for another topic - after I have reseated the ULA. IIRC it's an UK Electron. The German Electrons works fine with the MGC so the cartridge is not the problem.

Great work David and others that have worked on it.

BTW is there also a search option for finding games?

[davidb]

I have build a RGB to SCART cable today and tested mine. It works great! Good to see those old games again.
Unfortunately my Elk crashes after playing games for a while and I have unplug the power about five minutes and then it works again for about 10 minutes. But that's something for another topic - after I have reseated the ULA. IIRC it's an UK Electron. The German Electrons works fine with the MGC so the cartridge is not the problem.

If it's a UK Electron then it's probably just being lazy. Actually, I wonder if it might not be a different type of ULA to the ones in the German Electrons - perhaps those were supplied with later variants that were more reliable.

Great work David and others that have worked on it.

Thanks! It was fun to help with the project, though a lot more effort than I imagined it would be at the start.

BTW is there also a search option for finding games?

I think the others are working on adding a search option to the menu. It's not my area of responsibility.

[roland]

If it's a UK Electron then it's probably just being lazy. Actually, I wonder if it might not be a different type of ULA to the ones in the German Electrons - perhaps those were supplied with later variants that were more reliable.

Another difference is that the ula in the German Elk is soldered on the board. Not in a socket. That makes it also more reliable.

[daveejhitchins]

Roland . . .

You can list Games with a known first letter by using option 2 "Games Alphabetically". I don't have plans to add a search option for individual Games! Too complicated search code and, probably, not enough room left.

Dave H

[retroshaun]

Really interested in one of these! Email sent...

[daveejhitchins]

I've just updated the Spreadsheet here, as the MGC now supports Utilities and Applications . . .

If you have any ROMs that aren't listed please pm me with the details - thanks.

Dave H

[Hedge]

Great work on this project guys.

I was wondering would it be easy to emulate this particular device in B-EM
so more people can play with the code and make their own compilations?
Not the same as plugging one into a real elk or master of course, but for future projects
using the hardware, ( Like that giant 4mb game! ) it might be an idea.

Rgds
Hedge

[daveejhitchins]

Good luck with that, Hedge . . . If you or anyone taking up the mantle(?) needs any assistance just shout.

Dave H

[sadken]

Hi Dave,

For some reason i can't reply to your PM :/

Haven't sent you a list yet, got to wait for payday which is this Tuesday, I'll send an email then and sort out payment for you

Andrew

[danielj]

For some reason i can't reply to your PM :/

That's because you didn't have 25 posts. You should be able to PM now though!

d.

[sadken]

That's because you didn't have 25 posts. You should be able to PM now though!

Thought it might be something like that

Thank you

[davidb]

I was wondering would it be easy to emulate this particular device in B-EM
so more people can play with the code and make their own compilations?
Not the same as plugging one into a real elk or master of course, but for future projects
using the hardware, ( Like that giant 4mb game! ) it might be an idea.

As a quick hack for testing purposes, I changed Elkulator to expose different banks of data depending on the value written to address FC00. It should be pretty straightforward to do something similar for B-Em. Of course, it doesn't simulate the hardware with any accuracy, and the register at FC08 needs to be handled, but for simple tests it works reasonably well.

[00WReX]

Wow, I only just stumbled upon this.
This looks awesome.
I don't have enough posts to PM you, so will email.

Cheers,
Shane

[Elminster]

I think Dave you need to add a star rating to the spreadsheet or fit a bigger chip! How on Earth do you decide which ones to not get? Or just convert more games so enough to fit on two cartridges.

[MartinB]

Ok Dave, I'm soon going to push out for testing the in-Elk UPURS-based MGC loader as an update to the Elk UPURS rom. The utility is very straightforward (in operation, not quite so in implementation!) and simply accepts a start sector as the only command line parameter. The PC file is sent as usual and the MGC is sequentially programmed using the incoming image data stream. If the start sector is therefore set to A00 and a full 4Mb is sent, the entire MGC is programmed. The utility is very flexible in that the start sector can be specified as any of the 64 sectors in the device and the incoming image can be as short or as long as required with the only caveat being that the assumed file granularity is obviously 16k which represents one standard rom image. Looks like the time to in-situ program a complete MGC (i.e. 256 x 16k roms) is around 23 minutes from start to finish. I think for completeness that I need to add a closing full device checksum just to allow some optional integrity cross-checking if required but as I've come to expect from UPURS, I've never seen even a single bit error during development of the utility. In a day or so then....

(Note that this utility is for use by anyone with an MGC who wants a self-program capabilty but you also need an Elk User Port so an EUP or an AP5 etc. and UPURS)

[daveejhitchins]

Wow . . . Fantastic, as usual, Martin I'll be home Thursday/Friday so I should be able to test with a now working AP5 all down to the tremendous work of Dave (Hoglet)

I'll now be able to re-program a MGC without having to take the EEPROM off the board.

Dave H

[MartinB]

No rush whatsoever Dave, don't feel obliged I'm happily ticking over with final testing and tweaking so at some point soon I'll push out a beta rom image for testing by anyone with the means but again, no hurry....

[sadken]

That's awesome

Can you upload any rom to the cart?

[daveejhitchins]

That's awesome

Can you upload any rom to the cart?

it's a little more complicated than that as any ROM you want to use has to appear in the menu. I've created a spreadsheet for that purpose. A csv of the spreadsheet is then turned into a whole MGC contents file plus a set of 64K blocks. If you're just changing one game/application/utility then, as a minimum, you'll need to replace two (maybe just one if the game is in the same block as the index) blocks - one of which will contain the new index.

You can download the draft User Guide from the first page of this thread.

Dave H

[Elminster]

I read the whole thread from beginning to end the other day before deciding to get my MGC, very pleased with it, and it is amazing how the project has morphed over nearly 3 years. I made my UPURS cable ages ago, never got around to getting another serial to USB dongle though (works for serial on Sparc and Cisco kit but not the Beeb), now gives me a reason (once the AP5 is out as well) to get one.

Good work all.

[MartinB]

Can you upload any rom to the cart?

*UPMGC (the new utility) accepts a start sector as the only parameter and then expects to be able to pull data from the PC in contiguous grains of 16k (which represents a single rom) where these rom grains are used to sequentially program the MGC in bursts. I make the working assumption that a sequence of roms within a sector runs from 0-3 and the full sequence of sectors runs from A00-A1F followed by B00-B1F. (Hopefully this matches your expectations Dave?) This Read PC/Program MGC cycle continues until either the PC UPURS data stops or the last MGC sector is reached. You /could/ therefore load just one rom with this utility but only if that one rom happens to live as the first (of four) sequential roms within the specified sector. Personally, I'd recommend always working in a minimum of 64k sectors, so 4 x 16k roms, and I'd build appropriate compound image files on the PC as directed by the MGC mapping that Dave H has alluded to.

[MartinB]

Ok, I think we're ready to release a testing beta of the new UPURS MGC programming tools. I'll do the details over a few posts probably spanning today and tomorrow because its going to be necessarily a little long-winded but then aren't I always...?

There was an additional delay because whilst tinkering, I realised that even though we already have an MGC erase program, all the existing MGC utilities are disc-based and it transpires that this leads to a bit of a logistics problem with cartridge ports. If you are using the new UPURS loader, you will have the MGC in one Elk slot and some incarnation of an Elk User Port, currently likely to be EUP but down the line, perhaps an AP5, in the other slot. In this configuration, you can't then use floppies as I do because there isn't a free slot for the Peg or APxx disc interface. You could possibly use MMC (?) if you have two User Ports such as with EUP, but I decided that the best solution was to write a rom-based version of the existing MGC sector erase utility, *SECWIPE. To that end, the new release of the Elk UPURS rom, v2.0E, contains two new MGC configuration commands, *UPMGCER which is used to erase individual sectors or the entire MGC, and *UPMGC which is used to program the MGC.

Without trying to be too wordy in one post (ha ha, who? me?), here's what the new rom looks like when fitted....

The two new commands are at the bottom - I've stayed with a not-too-elegant UP... prefix since its always worked well with UPURS to avoid conflicts with the multitude of other roms out there.

The erase command first then is functionally identical to its *SECWIPE parentage where you either enter a single 64k MGC sector id in the range of A00-A1F or B00-B1F or 'ALL' to wipe the entire MGC device where with the latter, a confirmation prompt will be issued. Not terribly exciting but in use, *UPMGCER looks like this....



The programming command, simply *UPMGC, accepts either a single 'S', which invokes a Checksum-32 of the entire MGC taking about two and a half minutes (!) or a start sector at which programming will begin. As with the erase command, this MGC start sector is specified as A00-A1F or B00-B1F and if the entire MGC is to be programmed, this will be A00 and a 4Mb file must be sent from the PC. The programming is quite flexible in terms of extent so I'll cover all the possible outcomes in the next post but during programming, you'll see something like this....



More in the next post.....

[MartinB]

I'll jump to the checksum option first because it's fairly straightforward...

I decided not to include this as a default or follow-on option of the programming command simply to make life simpler because if you are programming less than the full device, you more often then not won't want to wait over two minutes for the checksum! So, at any time, to get the Checksum-32 of the entire MGC, type *UPMGC S and press enter. You will see the summing as it progresses but so as not to slow things down too much, there's no 'sparkle' activity indicator as with the programming utility but the checksum display is updated after every sector so you'll see 64 updates before the final output. Here's what you'll see...



...and when it's finished...

Most PC hex editors support the various checksum protocols so all you need to do is open the 4Mb MCG image on your PC with such a hex editor and select the Checksum-32 option. You can then compare this PC result directly with the output of *UPMGC S. ( Perhaps Dave H could additionally supply said checksum with any full MGC image files that he distributes? )

More on the programming utility probably tomorrow....

[vanpeebles]

Any word on a Master version yet?

[daveejhitchins]

Any word on a Master version yet?

Sorry, that's going to be a while! I'm over half way through the first batch of boards, though

Dave H

[danielj]

Make 'em wait Dave Elk First! Elk First!

[daveejhitchins]

@Martin . . . Looking Fab-u-lous - This alone will save me loads of time - as I'll be able to set the programming sequence going and get-on with something else

More importantly - users will have the tools to fully maintain their MGCs - which takes some pressure off me

Martin . . . Did you manage to add the "Remove MGC visibility from OS" before program start?

Dave H