Oerg's live dev cartridge thing!

[Oerg866]

Hi.

I present something i wanted to do for a long time now.

With this, you can have a base program running on the MD.

That fetches, using a mask of destiny cable, a small program from your PC, puts it in memory, and runs it. Useful for testing stuff, researching undocumented bits, etc. fast without flashing a cartridge or stuff like that. It actually jumps back too, so if your program has an RTS at the end, it jumps back and you can update your code and transfer it again.


Check the RAM program folder, it has another readme to get you started writing some code that runs from RAM. The RAM has a preset layout, which you can get used to very quickly, so you don't accidentally run into any surprises. And then i also included some routines, so you dont have to write them. (Like, load tiles etc.).

STEP 1: Get the base program running on your Mega Drive / Genesis.

You could, for example, use a flash cart, burn a ROM, or use any kind of weird approach.

STEP 2: Boot your console!

As soon as it works, you see a message on screen, prompting you to start a program and send your RAM blob.

STEP 3: Start the included "transfer.exe"

This program was written by Mask of Destiny for his transfer suite. Since we're using the same code to handshake and receive data on the console-side (it

is included in the sega CD ISO from him), we can use it.

It asks you to type in a filename. Type in the filename to your RAM blob and press enter.

Now it asks you to type in the base adress. Since we aren't on the sega CD with stuff being able to run from, like, EVERYWHERE and we don't have the Sega

CD's RAM.... we need to ignore that. Put in any value, doesn't really matter, and press enter.

Now it should say that it successfully shook hands. If it doesn't --- Bad luck. Normal parallel port diagnostics should be applied now. I found that the

same mode setup in BIOS etc, that you do for TOTOTEK flashcarts works well with this cable.

Now, 6 HEX digits appear on screen. This is for debug purposes. If anything goes wrong, tell me if these appear and if so what they contain.

And thats it! as soon as it's done, the program is loaded into the console's memory and should start. Gegeeee!!


Consult the readme for more info. I wrote a lot!

DOWNLOAD:

http://www.mdscene.net/~pvt/ramcart_v1.0.zip

IN ACTION:



Cheers,
Oerg866

[Oerg866]

[Archer]

this looks very useful, too bad it's windows only. and uses a parallel port which i do not have anymore. I have not looked at the demo code yet but do you know which side is in control of the transfer? Does the PC clock in the data to the MD, or is the MD pulling it in? I am asking because i want to try and write a linux version with an Arduino in the middle to translate usb/serial to the signals required.


EDIT:
I did look at the code now, and in the zip file i downloaded receive.asm is 0 bytes. I guess something went wrong there when you made it.

Here are the SHA1 and MD5 checksums of the file:
SHA1: 7fc33e4b6bc6c8ffdf96684a875f63f7ab904930
MD5: 6ba4649b40a443d802a61719d355fd61

EDIT2:
Went to the offical page and downloaded the US iso, and found sourcecode in there for receive. It seems to me the MD waits for the other end to initiate the transfer and that it is a synchronous protocol that uses a handshake after each nibble send. Not really sure yet how to know when a byte should start and keep it in sync.

[Oerg866]

this looks very useful, too bad it's windows only. and uses a parallel port which i do not have anymore. I have not looked at the demo code yet but do you know which side is in control of the transfer? Does the PC clock in the data to the MD, or is the MD pulling it in? I am asking because i want to try and write a linux version with an Arduino in the middle to translate usb/serial to the signals required.


EDIT:
I did look at the code now, and in the zip file i downloaded receive.asm is 0 bytes. I guess something went wrong there when you made it.

Here are the SHA1 and MD5 checksums of the file:
SHA1: 7fc33e4b6bc6c8ffdf96684a875f63f7ab904930
MD5: 6ba4649b40a443d802a61719d355fd61

EDIT2:
Went to the offical page and downloaded the US iso, and found sourcecode in there for receive. It seems to me the MD waits for the other end to initiate the transfer and that it is a synchronous protocol that uses a handshake after each nibble send. Not really sure yet how to know when a byte should start and keep it in sync.

Hi,

you should contact Mask of Destiny over on SpritesMind (or using his website heh) to get exact information. I copied receive from receive.asm to build.asm to not clutter up the place with too many files but forgot to delete receive.asm.

If you could get him to publically post information about the protocol, someone could write a nice multiplatform version. Not to mention tha tthis thing probably works fine with USB to LPT devices.

[Archer]

Hi,

you should contact Mask of Destiny over on SpritesMind (or using his website heh) to get exact information. I copied receive from receive.asm to build.asm to not clutter up the place with too many files but forgot to delete receive.asm.

If you could get him to publically post information about the protocol, someone could write a nice multiplatform version. Not to mention tha tthis thing probably works fine with USB to LPT devices.

Sorry, i did not see Receive in the other files when i gave it a quick look. it is actually in subs.asm btw.

I have been analyzing the ASM of the receive function and i think these are the steps it takes:

1.  Set port 2 pin direction: 00110000
      1-3 input
      4-5 output
      6   input
2.  Set outputs LOW
3.  Wait for bit 6 to go high
4.  Read data from port
5.  Shift to left (4 bits)
6.  Clear upper 4 bits (AND $F0)
7.  Set output's HIGH
8.  Wait for bit 6 to go LOW
9.  Set output's LOW
10. Wait for bit 6 to go HIGH
11. Read data from port
10. Clear lower 4 bits (AND $F)
11. Join the two values (OR)
12. Copy the new byte into ram (a0)
13. Set output's HIGH
14. Wait for bit 6 to go LOW
16. Exit, or wait for next byte

Since this code was inside the ISO on his site, and also your zip file, i do not think the protocol is a secret. We know what the receive function expects and how it responds. I think this is enough to create a linux/arduino based transfer program.

Thanks for sharing this, it does create a lot of interesting posibilities. Now i just need to find some time to get back into MD programming