UMDK Meeting Notes

[Chris Smith]

Hello all,

these are my Notes and Actions following the Meeting that took place between myself (Chris Smith) and Chris McClelland the other Week in London.

[Meeting]

I met Chris McClelland the other Week at his Home in London.

We set about trying to run some very simple Programs on the Real Hardware using the earlier UMDKv1.
What I realised very quickly was the extent to which the MD Emulators were very forgiving and that the Real Hardware will not tolerate any Alignment Errors or other irregularities - which means that we should be developing on the Real Hardware in fury :D

I had forgotten to bring along all of my Routines and instead tried to build a Binary using some very simple 'Hello World' Routines with Chris using GNU's gas (Assembler) crossed for the 68K.
We didn't have success though.

Chris had written a small Program for the MD that displayed a Simple List of Names that could be scrolled up and down.  Sadly this Program 'came out' garbled when we ran it using UMDKv1.  (*) a seperate Test using a Flash Device with the same Binary would determine if it was Chris's Program or the UMDKv1 at fault here-  My Money is on UMDKv1 but I cannot be certain at this Stage.

All the while we were able to run Sonic the Hedgehog from MD Cartridge without any Issues, so the Plot thickens...

Chris demonstrated a Session whilst running Sonic #1 on the Real Hardware.  The Session consisted of his UMDKv1 'up and running' (I am sorry but I do not fully understand how this works at this Time) and a DDD (think GDB if you haven't used it before) connected to the Megadrive!  Yes, for anyone out there who has been writing small Programs and Experiments under the Megadrive and running their Code under Emulators this is a God-Send to be sure :)
We were able to stop execute, inspect Registers - it was fantastic.
I needed to ask if we were able to somehow 'insert' our own Code to run by implanting our own Routines on the fly so to speak.  For example we could clear the VDP or make it do something else of interest - a Suggestion only at this Stage.

Chris showed me the fine work that he had done in getting the SMT ICs soldered to the UDKv2 Boards that he designed and had manufactured.  You'd be impressed to see how well the soldering turned out - Chris is Human make no mistake but the soldering is commendable :)

All in all it was a very useful Experience for me and I hope that other Developers with an Interest in the Megadrive will appreciate what Chris has managed to achieve.

[Future]

1. UMDK Usage

To be quite honest I do not understand how the various Parts and Subsystems come together to realise the Functionality in the UMDK.  I need to spend some Time with it to be in a better Position to make Statements and to provide Direction.  Although I have worked on Projects that had FPGA Systems in them, my Knowledge is very 'Black Box' at this Stage but I need to spend some Time with FPGA to answer a few Questions that I have.

2. Correct, Real Hardware ready Programs

Every Effort needs to be made on my Part to write Programs that will run on the Real Hardware and not just an Emulator to make real Progress.
It is also limited in Visibility to write Programs under Emulators.  I find myself often having to verify what is being written to the VDP by duplicating the Data and Commands written by also writing to the Work-RAM too - which is a bit tedious.  I know that you can look at the Tiles and Palettes in some MD Emulators but if you want to analyse then you often have to grab the Data from WRAM, save the File and then run it through your own Programs to check - all very long winded of course.

3. Experiment List

This is only a Suggestion:

It might be useful if we combined our Efforts more over by drawing up an 'Experiment-List' which would serve as Stepping-Stones in our Work.
If we had a Repository then we could draw upon the combined Experience to further our own Work Step by Step.

4. Unit-Tests

You may find yourself in one of those 'but that worked last Time, what has happened?' Moments often when writing this type of Software.
What about if we had a Battery of Tests available to test out the UMDK's Response to save us from tripping ourselves up all too often?
This is only a Suggestion at this Stage as I am aware of what this would Cost in Time and Effort.

5. Uptake

It really surprises as to how the MD Development Scene has not jumped at the Opportunity to assist Chris in his Efforts more over.
I do not know the Reasons why People have not focused on this Path to develop Software for the Megadrive but I feel that it would solve many of the inherent Problems.
I have found that the Tools that People use are 'all over the Place' in that there is not a single Platform or Method available with some using ancient Tools that have all manner of Hangups including outright Crashes (common to some Emulators too, I might add).  I have taken the Approach that I want Tools to work as simply as possible and in as many Places as they can.
As such, I have written Tools that are written in Standard C that run under Command-Lines - which means that most Unices and indeed Windows can use these Tools.

6. Costs

I'd like to pay my Share of the Components Costs, Chris :)

[Platform]

I am unsure how you were intending to move forwards with the Target Development Platform.
I personally use FreeBSD and Linux but I tend to do the Artwork (which is extremely simple) under Windows.

Did you have a Development Platform in mind?

[Suggested Additional Functionality]

1. VDP Access List

As discussed, it would be very useful if there was a VDP Access List available to assist in development and debugging.

In my Mind I would have Buffer-Space that contained the Type of Operation (be that Write-1, Write-2 or Read for Status), a Slot Number (set to active) - this could be realised as a Circular-Buffer.

It would then be very useful to have some kind of Application Software that would interpret the Accesses to the VDP.
I have Software already nobbled together that takes a set of VDP Register Values and Data and then displays what the Accesses mean.

Mode wise it would be useful to arrange for Blocks - Block-Mode of VDP Accesses to be written for later analysis and to have a Continuous-Mode that merely writes out the VDP Access each Time it occurs along with a Sequence-Number - large enough to cover a suitable Range.

I am unsure as to how the FPGA would realise this but one Idea is to have a Port over Ethernet or Serial-Port.
The Ethernet-Port Approach would merely be a Socket that the Application-Software would listen on.
The Serial-Port would be connected to a Terminal as a Client.

2. Access Lists for other Devices

The Megadrive is fairly thin on the Ground for Devices but it would be very useful if we could extend this Functionality to the following:

1. YM2612
2. PSG
3. Terminal-Ports: Controller-Ports for all MDs and the External-Port in the Case of the Megadrive #1 - the Original Version that included Altered-Beast.
4. Any other Devices that I have failed to recall :)

[Conclusion]

Many, many Thanks for having me over and for having demonstrated the UMDK - it was extremely useful for me to see it all in action :)

If anyone else could comment further or put down any of their Thoughts then please do.

Regards,

Chris Smith.

[Chris Smith]

Sorry, I meant to include an Example that works on my MD #1 (one of the early Machines) that I ran under an Emulator and ran on the real Hardware.  I need to check it using my MD #2 though to be sure.

I didn't write these Examples, a Guy on the Sprites-Mind Forum called Chilly-Willy wrote this 'Tic-Tac-Toe' Game.

Chris, see if you can run this using UMDK to see if you get the garbled output as you had with your Test-Program.

I could also run your Test-Program here on my MD #1 using my Everdrive Flash Device if you need me to.

Tbh it is really useful to have a number of Hardware Versions to test Things out on :)

Regards,

Chris Smith.

[Chris McClelland]

Minor clarification: the setup you saw was the Nexys2-based UMDKv2
prototype: http://www.makestuff.eu/wordpress/umdkv2-progressing-again/

I don't think I showed you the UMDKv1, which was really just a proof-
of-concept SRAM-based ROM emulator, with no debug capabilities:
http://www.makestuff.eu/wordpress/electronics/umdkv1/

The menu program of mine that you mentioned I wrote for UMDKv1 using
Stef's devkit: it *does* work on the UMDKv1 but as you mentioned it
comes out functional but visually corrupt on the UMDKv2. This will
almost certainly be due to the crappy PSRAM memory controller in the
UMDKv2 Nexys2 prototype, which is unable to handle the ~290ns VDP
reads from cartridge address space because they are rather shorter
than the 68000's reads. Interestingly, because the /AS signal is only
asserted during 68000 reads, it's clear that Sonic uses 68000 reads
almost exclusively (the only DMA from cartridge space Sonic does is
during the "Sega" sampled-sound ditty in the intro). As I've said
before there is no point trying to improve the latency of the PSRAM
controller because the standalone UMDKv2 board uses much cheaper and
much faster SDRAM (I've soak-tested my 84ns read, 63ns write SDRAM
controller for several days continuously writing, re-reading and
verifying many terabytes of random data).