UMDK manufacturing, part 2: Software

[Nemesis]

I agree we need more examples and a simpler "getting started" process. It's clear prophet isn't the ideal person to do this though, since he's not an expert on the Mega Drive itself. He's got the in-depth knowledge of the tool he built, and he can answer questions on it, but there need to be a few more Mega Drive experts with these devices in hand to play around with them and work out what kinds of cool things people would actually want to do with it, and how the hardware can achieve it, with prophet supporting that process by answering technical questions or troubleshooting issues with the UMDK. The most common types of processes could then be simplified through the use of some scripts, example code, and tutorials.

I'm between houses right now, with all my stuff in boxes. When I get it out again though, setting up my UMDK will be top of my list of things to do. Hopefully that'll all be worked out before the end of the year. As I follow on with configuring my UMDK, I'll do what I can do simplify the setup, and then I'll see what I can do about getting some examples together.

This is a really useful tool! We just need to learn how to use it. We're basically seeing the equivalent of what happens when you dump a Commodore 64 in front of people who've never used a computer. It boots up and they get a nice flashing cursor, then they'll say, "What do I do now? Is it broken?"

[MintyTheCat]

With UMDK uptake essentially being in single digits there was not much call for a UMDK community up to now.
My original intent was to get UMDK into the hands of MD Developers and hoped that the UMDK userbase would increase.

It is very useful and it really changes how you develop and the type of answers that you can get and how quickly - in short, it's marvelous and it is hoped that it will raise the standard

Tutorials, tools and other support will come along as more people use it, learn about it and want to develop with it as a natural follow-on.

Getting five more Developers using UMDK is a massive achievement, Montserrat and I am very pleased.

[Montserrat]

Would it be a good idea to move another 5x run to have 5 new testers? or it will be counterproductive?

[MintyTheCat]

Would it be a good idea to move another 5x run to have 5 new testers? or it will be counterproductive?

I haven't seen all the solder work that the manufacturer did on the five UMDK kits but we do know that they made some cock ups on the 68K's Address-Bus on your PCB. As such, I would either make them aware of what they did and ask them to take the necessary care with the work or search for a manufacturer that will do a better job.

But yes, this is one way to get UMDK manufactured for those who want one so maybe fire another batch off once all the basic testing have been done with the first batch of five.

[mikejmoffitt]

Regarding ease of "getting started", once we have all necessary binaries built both for the host computer and for the UMDK, they should be fully distributed in a "ready to go" package in addition to the build script.

Mine is still failing as the gcc-m68k build process is having problems. I'll grab the log when I'm off work.

[MintyTheCat]

Regarding ease of "getting started", once we have all necessary binaries built both for the host computer and for the UMDK, they should be fully distributed in a "ready to go" package in addition to the build script.

We discussed packaging the toolchain for the Raspberry-Pi but nothing further was done at the time.

We would have to benchmark the RPi's USB port to be sure that it can keep up with UMDK during trace-mode but if it worked out then that would be an easily solution and not too expensive either.

I have a PC dedicated to UMDK and I realise that these things take up space and cost money - so it would be a cool thing to have.

[prophet36]

Does someone else with more programming experience want to give it a go?

I was hoping someone else could try the flash-read test I proposed in a previous post, and then write up the process in detail for Montserrat, but nobody has done that yet, so here's my attempt at it:

Code: Select all

$ # Write a 512KiB random-data file to flash using spi-talk.xsvf and gordon...
$ cd ${HOME}/umdkv2-bin
$ flcli -v 1d50:602b -p J:A7A0A3A1:spi-talk.xsvf
  :
$ dd if=/dev/urandom of=random.dat bs=1024 count=512
  :
$ gordon -v 1d50:602b -t indirect:1 -w random.dat:0
  :
$
$ # Load sigtest.xsvf so we can execute the flash-readback test
$ wget -q www.swaton.ukfsn.org/umdkv2/sigtest.xsvf
$ flcli -v 1d50:602b -p J:A7A0A3A1:sigtest.xsvf
  :
$
$ # Build a flash-read test that copies 512KiB from flash into SDRAM at 0x400000...
$ cd ${HOME}/20150315/makestuff/hdlmake/apps/makestuff/umdkv2/gdb-bridge/monitor
$ cat > test.s <<EOF
    SPIDATW  = 0x0000  /* SPI word read/write */
    SPICON   = 0x0004  /* SPI interface control */
    bmTURBO  = (1<<0)  /* 0x0001 */
    bmFLASH  = (1<<2)  /* 0x0004 */

    .org     0x000000

    dc.l     0x000000  /* Initial SSP */
    dc.l     0x000008  /* Initial PC */
boot:
    move.b   0xA10001, d0
    andi.b   #0x0f, d0
    beq.s    1f
    move.l   #0x53454741, 0xA14000  /* write "SEGA" to TMSS register */
1:  lea      0xA13000, a0
    lea      0x400000, a1
    move.w   #(bmTURBO | bmFLASH), SPICON(a0)
    move.w   #0x0300, SPIDATW(a0)   /* 03 = "read flash" command; next three */
    move.w   #0x0000, SPIDATW(a0)   /* bytes set the read offset to zero. */
    move.w   #0xFFFF, SPIDATW(a0)   /* get first two bytes */

    /* Load four chunks of 64KiB from flash, copy them to SDRAM at 0x400000 */
    move.w   #0xFFFF, d0
2:  move.w   SPIDATW(a0), (a1)+
    dbra     d0, 2b
3:  move.w   SPIDATW(a0), (a1)+
    dbra     d0, 3b
4:  move.w   SPIDATW(a0), (a1)+
    dbra     d0, 4b
5:  move.w   SPIDATW(a0), (a1)+
    dbra     d0, 5b

    /* OK, we're finished copying, so go into an infinite loop */
6:  bra.s    6b
EOF
$ make test.bin
  :
$
$ # Now load test.bin and start it executing...
$ loader -w test.bin:0 -x 2
  :
$
$ # *** Wait a couple of seconds to give it a chance to finish ***
$
$ # Now read back the 512KiB that the test has copied from flash into SDRAM...
$ loader -r readback.bin:0x400000:0x80000
  :
$
$ # ...and compare it with the original random-data file...
$ cmp readback.bin ${HOME}/umdkv2-bin/random.dat
$

Notice that there are no diffs reported by the "cmp" command. This proves that my MegaDrive can reliably read the data stored on the UMDK's flash chip. Note that this will leave your UMDK in a non-bootable state (obviously, since the flash got overwritten during the test). To restore it to how it was before, you just have to re-load the fpga.bin and firmware.bin files:

Code: Select all

$ cd ${HOME}/umdkv2-bin
$ flcli -v 1d50:602b -p J:A7A0A3A1:spi-talk.xsvf
  :
$ gordon -v 1d50:602b -t indirect:1 -w fpga.bin:0
  :
$ gordon -v 1d50:602b -t indirect:1 -w firmware.bin:0x60000
  :
$

[Montserrat]

I was hoping someone else could try the flash-read test

I did the test comparing the 2 readings, thanks for comenting the commands, that was very nice.

The compare command did not returned any result so im assuming they're identical.

[prophet36]

they're identical

That's great! But if that's the case I can't see what can be wrong with DDD. You said you get the same behaviour as Burbruee, presumably meaning you have to load the menu program manually (using "loader"?) right after the console powers on? TBH I was a bit unclear about Burbruee's workaround. Also, just so I understand correctly, when you said DDD just hangs, did you remember to start the gdb-bridge in another window first?

[prophet36]

once we have all necessary binaries built both for the host computer and for the UMDK, they should be fully distributed

In my experience, that is kinda problematic. Binaries don't work too well if you build on one distro and use on another. Are you still having trouble building the software? Which distro & architecture? If I get time I'll try to work out what's going wrong, and perhaps have the build process detect your platform and do the right thing.

Having said that, binary distribution is definitely an option for the Windows build, but that still needs some work put into it to get a useable gdb front-end.

[Montserrat]

they're identical

That's great! But if that's the case I can't see what can be wrong with DDD. You said you get the same behaviour as Burbruee, presumably meaning you have to load the menu program manually (using "loader"?) right after the console powers on? TBH I was a bit unclear about Burbruee's workaround. Also, just so I understand correctly, when you said DDD just hangs, did you remember to start the gdb-bridge in another window first?

Let me summarize:

UMDK standalone -> blackscreen
UMDK burbruee workarround -> SD-CARD menu.

so

DDD will work if you load a rom FROM the SD-CARD menu then stablish GDB-BRIDGE.
DDD will work if you load a rom FROM the terminal,ONCE the SD-CARD MENU its on screen.

I've made a video with the workarround process and a final surprise... check it now please (warning crappy english ahead):

https://youtu.be/b_zQk2P9G-g

On the final surprise...i couldnt make it work into the nomad after that, i've tried a tons of times and never worked, i think the workarround works but the timing needed is much much more precise in the nomad, i got lucky in the video.

[Burbruee]

Oh, Montserrat, I was under the impression that your nomad would only ever show a black screen, even with the workaround. So normally it gets to Reading files from SD and stops there and never lists any files? Is it normally possible to use loader again at this point to load up a game and run gdb-bridge?

If yes then that sounds exactly like both of my PAL MD1 are behaving, I never get past the loading files and have been unable to load anything from SD, it's only possible with loader because it stops on reading files in the menu.

prophet: I still haven't done any traces of any of the sonic 1 exceptions with loader, I'll see if I can find the time soon. You were saying a few times it was as if the usb connection was unable to keep up and it has shown garbage in a few of my tests and other times worked fine. Not sure what's up with that.. This laptop is fairly recent and only has USB3, no USB2. Maybe something with the usb3 controller not sure. Haven't had anything else connected when I've done any previous tests.

[mikejmoffitt]

once we have all necessary binaries built both for the host computer and for the UMDK, they should be fully distributed

In my experience, that is kinda problematic. Binaries don't work too well if you build on one distro and use on another. Are you still having trouble building the software? Which distro & architecture? If I get time I'll try to work out what's going wrong, and perhaps have the build process detect your platform and do the right thing.

Having said that, binary distribution is definitely an option for the Windows build, but that still needs some work put into it to get a useable gdb front-end.

Sorry, I should have been more clear.

I am referring to binaries of the firmware that will go on the UMDK. I am having trouble building the software on Debian Stretch x86_64. Part of it has to do with building the gcc 68k toolchain. The actual utilities have built fine, and I believe it is just the firmware going to the UMDK that is having trouble. That is what I'd hope for a binary for. I already have a gcc-68k toolchain on my install as well, so I will not be missing much skipping it here.

Here is my x64.log: http://csh.rit.edu/~moffitt/x64.log

[Montserrat]

Oh, Montserrat, I was under the impression that your nomad would only ever show a black screen, even with the workaround. So normally it gets to Reading files from SD and stops there and never lists any files? Is it normally possible to use loader again at this point to load up a game and run gdb-bridge?

Nomad shows the "makestuff sing" using the workarround always, except for the lucky time when i was recording that video. I am unable to replicate that, i've tried for a few hours but i cant get through the "makestuff sing".

I can load roms to memory using terminal, even stablish the GDB-bridge and using the DDD, all via terminal.

I was thinking what chris said about the pc being incapable to move all data. This laptop is a very limited machine a single core celeron below 2ghz, DDD takes ages run commands, so im gonna try using a virtualized debian in my desktop and see what happens.

[prophet36]

https://youtu.be/b_zQk2P9G-g

You sir are awesome. No doubt about it. Also, I'll say it again: your English is pretty much perfect.

OK so Burbruee's workaround gave me an idea, which I wish I had thought of when I was originally debugging the menu program. I'm not even 100% sure why it works, but it seems like you can trace the execution of the complete startup-sequence, from when the MD starts up and begins executing the first-stage bootloader all the way through loading stuff from flash and the menu program executing. It may not be obvious, but that is very very very cool, and it gives us an amazing weapon in the process of debugging wayward UMDK carts.

So, please do this. Take your SD card out of your UMDK, and then plug your UMDK into your MD1. Set the region-switch to EU. Power the MD on, and very quickly afterwards (as if you were doing the Burbruee workaround), do this:

Code: Select all

loader -t boot-trace.log

Let it run for about six seconds, then hit ctrl-c. If you get "Could not find any 1d50:602b devices" then you need a bigger delay between powering on and running the command. The boot-trace.log file should be about 70MB. I'm expecting your MD1 to just show a black screen. If you bzip2 the file:

Code: Select all

bzip2 boot-trace.log

...it should go down to less than 30MB. Then upload the trace.log.bz2 file somewhere. I'm hoping there will be enough trace information available to give me an idea what's going wrong. I'd like to get to the point where you & Burbruee can boot (without any workarounds) to the MakeStuff splash-screen when you power on without an SD-card loaded.

Later on, we can find out why your Nomad almost always stays on the MakeStuff splash-screen with an SD-card is loaded. I suspect that's due to a timing problem, and should be relatively easy to fix.