UMDK manufacturing, part 2: Software

[prophet36]

Alright, it's finally done

Thanks!

Same problem: there seems to be contention between the Z80 bus arbiter and the 68000, causing address-bus instability after /OE asserts.



Interestingly though, it does seem to follow a very similar pattern to Montserrat's trace - the address is unstable two 48MHz cycles after /OE asserts. More aggressive debounce logic might fix this: basically ignore /OE until it has been asserted for three consecutive cycles. That approach won't work for DMA cycles because the SDRAM is only just fast enough to serve them even without more debouncing logic, but we can detect DMA cycles (they assert /OE whilst /AS remains deasserted) and hope they don't suffer the same kind of bus contention.

Unfortunately I'm not going to have time to look into that for several weeks at least, but I'm happy to help if someone else wants to have a crack at it. In the meantime you could either buy a more recent console from eBay (e.g a PAL MD2) or if you prefer you could just give up entirely and sell your UMDK cart to BigEvilCorporation who was the only person to reply on the "2nd-batch" thread.

[Montserrat]

Well im gonna start coding some game, as you recomended im learning C now with some nice books from the local library.

Also, do you know how to setup sgdk (Gendev) in linux? I've already did in windows but in order to work with UMDK i prefer to work in a only linux enviorment.

I've tried original instructions but i must be doing something wrong...i'm using codeblocks as ide.

[MintyTheCat]

Well im gonna start coding some game, as you recomended im learning C now with some nice books from the local library.

Also, do you know how to setup sgdk (Gendev) in linux? I've already did in windows but in order to work with UMDK i prefer to work in a only linux enviorment.

I've tried original instructions but i must be doing something wrong...i'm using codeblocks as ide.

If you look in the UMDK directory it actually has an SGDK that will work under Linux.
I am not on my dev machine now but if you cannot find it let me know and I will give you the path.

[prophet36]

do you know how to setup sgdk (Gendev) in linux?

I install it as described in the Wiki here.

[prophet36]

If you look in the UMDK directory it actually has an SGDK that will work under Linux.
I am not on my dev machine now but if you cannot find it let me know and I will give you the path.

That's only true if you build everything from source. I suspect most people are using the 20151220 binary release.

[MintyTheCat]

If you look in the UMDK directory it actually has an SGDK that will work under Linux.
I am not on my dev machine now but if you cannot find it let me know and I will give you the path.

That's only true if you build everything from source. I suspect most people are using the 20151220 binary release.

I see. I have both but do not use SGDK myself so it is a fair cop

[Montserrat]

Wooops im sorry im bringing more problems.

I was trying to load some assembly coded roms into the umdk but all i can get is black screens or weird mosaics.

i've tried some color test i coded, some of the BigEvilCorporation scrolling tests, and one from Mark's real blog, but umdk seems to not like assembly coded stuff. (those works on emulators)

SGDK stuff works fine btw.

the test:

https://mega.nz/#F!OV1nDThT!xs1SqyHlwrvtkjGRIlVKVQ


pd: Also loading DDD in linux mint goes back to sd-loading screen and crashes. Debian works fine.

[prophet36]

Wooops im sorry im bringing more problems

Unfortunately I've had to pack away my UMDK stuff to make room for a new project so I won't be able to check it for a while. It's not unheard of for things to work in emulators but not on real hardware though. Has anyone got a regular flash-cart they can try Montserrat's .bin files with?

[MintyTheCat]

Wooops im sorry im bringing more problems.

I was trying to load some assembly coded roms into the umdk but all i can get is black screens or weird mosaics.

i've tried some color test i coded, some of the BigEvilCorporation scrolling tests, and one from Mark's real blog, but umdk seems to not like assembly coded stuff. (those works on emulators)

This can be:

1. linker script issue.
2. odd offset issue - must be Word aligned.
3. linking issue - check your build operation.
4. ROM generation issue - are you passing in the sections of say the ELF or COFF to your ROM file to be?
5. Checksum issue: many MD apps and games check their ROM image after initialisation to check to see that the ROM image is not corrupted - highly unlikely with your own code but if you have borrowed code from someone else this may happen and you shall need to either disable it or recalculate your ROM and write in the checksum for the modified ROM.
6. MD header is wrong or does not exist.
7. MD Interrupt-Vector Table is wrong or does not exist.

SGDK stuff works fine btw.

the test:

https://mega.nz/#F!OV1nDThT!xs1SqyHlwrvtkjGRIlVKVQ


pd: Also loading DDD in linux mint goes back to sd-loading screen and crashes. Debian works fine.

SGDK built code will produce correctly aligned ROM files but when working in Assembly it is very easy to create an odd alignment.
I will have a look at your ROM tomorrow to check.
Have a look at the generated Listing and Map files.
Also, always check things on a Emulator if you suspect your code is misbehaving on the real Hardware. I can advise you use GENSIDA, Exodus or MESS.
Single step through your code; your code should definitely get past the initiailisation code - if it does and you are getting either nothing or something very weird then it may well be that you have no correctly configured the MD for use.

I will have a look tomorrow for you and also provide you with a simple example that 100% works.

[Montserrat]

Sry forgot to say that all those test roms, DOES WORK on emulators, regen, mess...(including my own coded test), but does not work in umdk.

BigEvilCorporation test was compiled using SN systems asm68k.exe for the hscrolltest.bin

Mark's realm test was already compiled (just downloaded to test) he used m68k-coff-gcc.

[MintyTheCat]

I had a look at the Scrolltest ROM tonight. It had an issue with its Vector-Table, Header and alignment. I have repaired it but there is still an issue that I will have a look at most likely on Friday as I have some other outstanding tasks to work on.

This is *NOT* an issue related to UMDK - the clue was that ROMs compiled from C ran under UMDK.
This is a classic example of how Emulators lie to us all - but the real hardware never lies, and neither does the Assembly

[MintyTheCat]

Sry forgot to say that all those test roms, DOES WORK on emulators, regen, mess...(including my own coded test), but does not work in umdk.

No, you mean it does not work on the real hardware - this is NOT UMDK to blame here. I always check anything related to suspected hardware issues with at least two methods of flashcarts, use the Logic-Analyser to check and it is always me who has made the mistake and never the hardware

BigEvilCorporation test was compiled using SN systems asm68k.exe for the hscrolltest.bin

It doesn't matter which Assembler was used tbh but the linker script/layout matters. Perhaps Matt at that time had not tried his tutorial code out on real hardware - you will have to raise that with him. I do not have his sourcecode but I was able to repair the ROM and run it.

Mark's realm test was already compiled (just downloaded to test) he used m68k-coff-gcc.

Again, the Makefile is most important here and the linker-script.

[Montserrat]

BigEvilCorporation test was compiled using SN systems asm68k.exe for the hscrolltest.bin

It doesn't matter which Assembler was used tbh but the linker script/layout matters. Perhaps Matt at that time had not tried his tutorial code out on real hardware - you will have to raise that with him. I do not have his sourcecode but I was able to repair the ROM and run it.

Mark's realm test was already compiled (just downloaded to test) he used m68k-coff-gcc.

Again, the Makefile is most important here and the linker-script.

I'm seriusly confused.

whats the linker script/layout? how do you repaired the rom?

Also. No matter how many things i try im unable to make DDD work again with UMDK. (it only works in the laptop i used to do the test of this thread, posibly because it has some old "release")

In the very first moment i launch DDD menu, the megadrive goes back to the game selection menu, any ideas?

[MintyTheCat]

BigEvilCorporation test was compiled using SN systems asm68k.exe for the hscrolltest.bin

It doesn't matter which Assembler was used tbh but the linker script/layout matters. Perhaps Matt at that time had not tried his tutorial code out on real hardware - you will have to raise that with him. I do not have his sourcecode but I was able to repair the ROM and run it.

Mark's realm test was already compiled (just downloaded to test) he used m68k-coff-gcc.

Again, the Makefile is most important here and the linker-script.

I'm seriusly confused.

whats the linker script/layout? how do you repaired the rom?

https://en.wikipedia.org/wiki/GNU_linker
https://gcc.gnu.org/wiki/Building_Cross ... chains.pdf
http://www.delorie.com/gnu/docs/binutils/ld_6.html

Essentially, it tells the Linker program where to place various sections of objects in the output file - be they generated from high-level sourcecode from say C or C++ or more low-level sourcecode as in the case of Assembly language. This gives us direct control over how the MD ROM in our case is created. Read up on Text, Data, BSS and various other sections to get an idea:

http://www.nongnu.org/avr-libc/user-man ... tions.html

To be honest this is a more involved subject and most of the time on say a PC when we are building Applications we usually are less interested in how the sections are linked together to form the output file. On the other hand when working in embedded development you will solving your ROM layout early on. Some Operating-Systems have a very specific layout, e.g. QNX and VXWorks and some projects have no OS at all and are said to be 'bare-metal' - in our case, the Megadrive is bare-metal.

Also. No matter how many things i try im unable to make DDD work again with UMDK. (it only works in the laptop i used to do the test of this thread, posibly because it has some old "release")

In the very first moment i launch DDD menu, the megadrive goes back to the game selection menu, any ideas?

Ok, can you post up what you are entering on the command-line please?

E.g.

Code: Select all

 loader -v <UMDK dev class: UMDK device ID> -w <ROM file/data>:<address> -x 2

Also, can you post your GDB log please? You will find it here:

/var/tmp/gdb.log

Are the installations of the UMDK toolchain that you installed on your laptop and PC using the same Operating-System and version?
Please enter on the command-line this and copy the answer back and post it here:

Linux <machine's name> 3.16.0-4-586 #1 Debian 3.16.7-ckt11-1+deb8u6 (2015-11-09) i686 GNU/Linux

I have UMDK installed under Debian 8 ~Jessie and an older version of Ubuntu and both work.

Also, type in this:

Code: Select all

which ddd
ddd -v

I get this under Debian 8:

which ddd
/usr/bin/ddd

ddd -v
GNU DDD 3.3.12 (i486-pc-linux-gnu)
Copyright (C) 1995-1999 Technische Universität Braunschweig, Germany.
Copyright (C) 1999-2001 Universität Passau, Germany.
Copyright (C) 2001 Universität des Saarlandes, Germany.
Copyright (C) 2001-2009 Free Software Foundation, Inc.

Can you run the built GDB without running DDD?

Montserrat: did you get the E-Mail that I send to you last night with a working Assembly project included?

[Montserrat]

Sry i will look to all of this soon, im pretty busy this days, but im in.