Forums

My new project using ATMEGA328P, my goodbye to 8bit MCU's as they are a bit boring and I want to move to 32bit.

https://github.com/L10N37/MD-Fuhrer/tree/main

Check it out, Thanks Raphnet for the stack pointer page. I rewrote this my own way to understand it a few years back which helped immensely as I just put my own version in notepad, made a bunch of notes of which pins toggle and ported it to a PIC16F628A which I chose a few years ago. It's perfect for this. It just sat in a drawer because I lost my kicad files for my SMS pin adapter.

I devved on Model 2 VA1 JP/ PAL. JP wouldn't toggle 50/60hz, moved to PAL board. I think the 315-5660-10 was either bad on that pin or hard locked to 60Hz?

The internal pull-up didn't exist, so it was 'floating' but stayed in 60Hz.

It does NTSC443, PAL60, Straight PAL, Straight NTSC all with button combinations. SMS pause with button combo held a couple seconds, and stack pointer init on the PIC mentioned above.

I don't know if I'll ever get around to PCB's etc.

It uses a 5v mini relay to short the reset button and save settings on reset if you change any modes. JP / ENG is also on toggle with a button combo.

Benefits:

Cleans up the shitty composite of NTSC consoles. No rainbows anywhere, no banding.

Full DFO, multi region. 50/60hz, correct refresh rate. Toggle Sub carrier for the modes. No invalid modes available. Well, other than PAL JP.

I'm sorry I must ask, but why did you call it the Fuhrer?

I think that Fuhrer=Leader. Im not sure.

Yeah it's just german.
Hitler baby.

If anyone can help.

My original stack pointer set up (late at night, after work)

My version stupidly had 9 bits. Ignoring the last bit 8 as I was using binary not hex and assume the compiler would ignore that I would have sent

21
01
A1
25
B9
C7

I have no idea what this translates to when its sent down the cart bus, but all the games requiring stack pointer set up were loading. Good audio, no garbled graphics etc.

The archived discussion is here:

https://web.archive.org/web/20190403192608/http://www.smspower.org/forums/14084-...

The correct bytes are now in my source code for the PIC chip.

#include <xc.h>
#include <pic16f628a.h>

// Config bits
#pragma config WDTE = OFF // Watchdog Timer disabled
#pragma config PWRTE = OFF // Power-up Timer disabled
#pragma config MCLRE = OFF // MCLR pin function is digital input
#pragma config CP = OFF // Code Protection disabled

#define wait_() while (PORTAbits.RA5 == 0) {;} // wait for RA5 high again
#define wait() while (PORTAbits.RA5 == 1) {;} // wait for RA5 low pulse

uint8_t send[6] = {0x21, 0x01, 0xE1, 0x25, 0xF9, 0xC7};

void init(void);

void main(void) {
init();

while(1) {

for (int i = 0; i < 6; i++){
wait();
PORTB = send[i];
wait_();
}

// All pins high-z
TRISA = 0xFF; // Set all pins of PORTA as inputs
TRISB = 0xFF; // Set all pins of PORTB as inputs
// Sleep MCU
SLEEP();
}

return;
}

void init(void) {
// Configure RA5 as INPUT
TRISA5 = 1;

// Configure RA0 as OUTPUT
TRISA0 = 0;
// CE PIN HIGH through 1.5k Resistor
RA0 = 1;

// Configure RB0 through RB7 as OUTPUT
TRISB = 0x00;
}

Fairly simple, now shinobi is ok. The audio is good and it doesn't randomly reset. R-Type would reset sometimes. Basically randomly, but usually at boss fights. This was the only issue with the initial one, R-Type.

I played around with this a lot but usually Aztec adventure has sprite corruption and the intro screen is a garbled mess, shinobi will have audio drop after a few seconds into stage 1 and random resets, depending what you send.

Sticking 'by the books' above, aztec adventure (which was initially fine) is doing the graphical corruption.

Decoding Ralphs code, which is a massive headf*ck because D0 is tied high perma and some pins that don't exist on his MCU (PORTB bit 6/7) are always set to 0 for bit 6 and 1 for bit 7, which I ignored. Also the fact the bytes are split between PORTC and PORTB because the MCU doesn't have an 8 bit bus available. (portD has bit 0/1 taken by RX TX for UART)

He seems to present initially

0x12
then the read cycles start he sends again
0x12

Then through the read cycles the 'by the books' from the offical converter dump.

0x21
0x01
0xE1
0x25
0xF9
oxC7

Also, I don't think it can be a part of this project anyway.
The EverDrive clone I have doesn't like this happening at boot. It's ok to boot to the menu but chaos in games if they load. Stand alone megadrive game cartridges seem to be fine though.

So maybe hard wiring it to the actual console and not as part of an adapter is a no no.

I am happy to give up for now.
Just confused on Aztec Adventure being a c*nt.

I've wasted enough time on this :P

Also, I did try using an MCU to sniff the 8 bit BUS using official pin adapter with the ROM, but readings varied too much. If 16MHz MCU can not read reliably using the same method as sending the data not sure how a 4MHz one can get these loading 100% of the time when wired in.

Read outs:

Waiting for power on
1
00000001

A1
10100001

1
00000001

E1
11100001

F9
11111001

C7
11000111

END OF CAPTURE

Waiting for power on
1
00000001

21
00100001

1
00000001

E1
11100001

F9
11111001

C7
11000111

END OF CAPTURE

Waiting for power on
1
00000001

21
00100001

1
00000001

A5
10100101

F9
11111001

C7
11000111

END OF CAPTURE

Waiting for power on
11
00010001

A1
10100001

1
00000001

E1
11100001

F9
11111001

C7
11000111

END OF CAPTURE

Simple capture code, right shifts PORTD captures one bit to the right shoving out RX, then sets TX to perma 1 (D0 tied high) and writes out final bit from PORTB (D7) into bit position 7.

#define outputEnableHigh (bitRead (PINB, 1) == HIGH)

void setup() {
DDRD &= ~(B11111100);
DDRB = 0x00;

Serial.begin (115200);
}

void hang(){
hang();
}

void loop() {

TRYAGAIN:

uint8_t capture[6];
bool captureD7[6];

Serial.println ("Waiting for power on");
while (bitRead (PINB, 4) == 0); // wait here until consoles powered on (digital pin 12 to VCC plane on console)

for (int i=0; i<6; i++){
while (outputEnableHigh);
captureD7[i] = bitRead (PINB, 0);
capture[i] = PIND;
while (!outputEnableHigh);
}

for (int i = 0; i <6; i++) {
capture[i] = capture[i] >>1;
bitSet(capture[i], 0);
bitWrite(capture[i], 7, captureD7[i]);
}

for (int i = 0; i < 6; i++){
Serial.println(capture[i], HEX);
Serial.println (capture[i], BIN);
Serial.println (" ");
}
Serial.println (" END OF CAPTURE ");
Serial.println (" ");

while (bitRead (PINB, 4) == 1); // wait here until consoles powered off
goto TRYAGAIN;

hang(); //stopped using this as always had to reset

}

Quote

Yeah it's just german.

Danke

Quote

Hitler baby.

Im not nazi. Im just studied a bit of german.

segarule wrote

Quote

Yeah it's just german.

Danke

Quote

Hitler baby.

Im not nazi. Im just studied a bit of german.

This definitely wasn't aimed at you, they called Hitler the Fuhrer.

Just to be clear: using the work Fuhrer is likely to make people think of Nazi history, and this might upset some people. Use it at your own risk. SMS Power official position on Nazis is that they are bad.

Thanks for reminding me of that lost forum topic; I've resurrected it from an old backup: https://www.smspower.org/forums/14084-PowerBaseConverterInfo

And, since it seems not to be very clear (to me at least), this is a (not yet completed?) mod chip for a Mega Drive which seems to implement a few nice things:

* Control pad control of region (Japan/Export) and speed (50/60Hz), with persistence
* Stack setting like the original Power Base Converter, for better compatibility when using other such converter cartridges/Everdrive
* Control pad for SMS pause button when playing SMS games

Please correct any misunderstanding!

Maxim wrote

Just to be clear: using the work Fuhrer is likely to make people think of Nazi history, and this might upset some people. Use it at your own risk. SMS Power official position on Nazis is that they are bad.

Thanks for reminding me of that lost forum topic; I've resurrected it from an old backup: https://www.smspower.org/forums/14084-PowerBaseConverterInfo

And, since it seems not to be very clear (to me at least), this is a (not yet completed?) mod chip for a Mega Drive which seems to implement a few nice things:

* Control pad control of region (Japan/Export) and speed (50/60Hz), with persistence
* Stack setting like the original Power Base Converter, for better compatibility when using other such converter cartridges/Everdrive
* Control pad for SMS pause button when playing SMS games

Please correct any misunderstanding!

It's not to offend anyone.
Yes, Nazi's are bad.

Not just region pad, these are tied together with encoder pad. You cut /separate these traces so they no longer 'agree' with each other.

Now you can choose 60Hz master clock, PAL encoded @ 60Hz.
PAL60.

Full modes:

PAL60
NTSC443
NTSC
PAL

Japanese / english toggle.

The only unofficial type of mode I left in was normal PAL mode but you could select JP on this and get JP PAL.

You can also pause the console by holding BTN1 + BTN2 + DN for a couple seconds.

It will detect SMS controller vs Megadrive controller. It's not polished yet.

The Atmega328P side of things is close to finished and just needs some more testing and stuff.

I decided to implement the stack setting on a separate chip as I am out of I/O pins on the Atmega328P (nano/ uno for now + SI5351 dev board, until proper PCB is measured out and designed nicely)

The dev board is fine @ 5v, has regulator and level shifting components.

PCB would need 3.3v regulator.

Clocks are fine @ 3.3v, i have a component here that can level shift all the way up to 100MHz fine, but it's not required. Console is happy with 3.3v clock out.

So the board outputs

NTSC / PAL Master clocks
NTSC / PAL SubCarriers

This is why you can get all those video modes.

It really helps in NTSC Megadrives where they seem to do rainbow colour output all over the place. Mainly the white's you'll see it, and from what I've read online some will do really bad rainbow banding.

I think this is the sub carrier derived from master clock through division in the VDP. It travels a long distance across the board, right past the main power input / 5v reg on model 2.

So now you get clean composite in all modes.

I did use 1.2k series resistors on what ever on D10 / D11 (I think 50/60Hz toggle and encoder mode toggle) because there was a little residual voltage on those pins when floating. The 50/60Hz was a full 5v VCC from an internal 1k pullup. It probably wouldn't hurt to connect these directly.

The pause output needs to be connected directly.

The reset / save settings (board saves modes on reset) which is A+B+C+START is done through a 5v mini reed relay. The reset circuit needs direct S/C 5v to GND (im sure it's through some protective resistors somewhere but i can't find them) and you just kill I/O pins pulling it to ground. This way the MCU just sends a high to the relay, the relay throws an internal switch which is equivalent to pressing the reset button.

This would cover active high and active low reset circuits found on model1 / model 2.

Now what I am confused about as mainly posted about on this thread, is the stack set up which I'd like to have as part of the board. There are 8bit atmel MCU's with way more pins, good price, but no dev board for them, hence, I moved the code across to the PIC16F627/628A.

My first version as mentioned, booted every game requiring stack pointer set up 100% of the time. It was just that R-Type was resetting randomly.

Since trying to fix it, It's just gotten worse. Where it stands, it should be sending the required bytes at boot but this interferes with some Megadrive games when using Mega EverDrive and Aztec adventures boots with graphical corruption. I'm also having trouble black-boxing the official adapter by capturing it's output and ignoring what's on the ROM. I can only catch the 0x25 if I instead switch it to catching bytes while OE is high (instead of low) and there's no consistency. I probably should hook up a logic analyser, but it seems pointless when the work has already being done. Some clarity on why Ralph sends that first byte would be good, and why I can't catch what it does on the BUS through my capture code with consistency as those were just the best captures out of handfuls.

If anyone wants to try it out (without the stack pointer set up for SMS games, which is a separate chip)

The combos should be

A+START+ (left, right,down or up) for all 4 video modes.
The source is pretty well commented.
It's also easy to read, everything is in a function and it's just pin toggling.

oh .. and JP/ENG toggle is A+B+ST

Also, happy to change the name if i ever get around to polishing it and turning it into a proper kit. Lets just keep fuhrer as prototyping.

I got this stack pointer set up working.

https://www.smspower.org/forums/18459-RTypeOnMegadrivePowerBaseConverter

This page confused me,

quote:

"The RAM will be disabled if the byte read from $c000 has bit 4 set. However, the official converter contains a tiny Boot ROM which should prevent this from happening - the code in the ROM both initializes the stack pointer and writes $00 to $c000 (via the mirror at $e000)."

However this blows it out to 10 bytes and didn't seem to work.
Games glitch, aztec has graphical corruption.
Shinobi sound disappears and resets very shortly into level one or hard locks.

I can't see how this happens (what is quoted)

I cut to the chase. I can drive the 8 bit bus, all 8 bits.
I am not restricted to some instruction work arounds that involve having one bit tied high because I have only 7 pins to work with.

LD SP, $DFF0 ; Load the stack pointer (SP) with the value $DFF0

{0x31, 0xF0, 0xDF};

I did listen to the comments about that being a better memory address than where they could land with hack around instructions.

So far all good, no power and gnd on the PIC chip as the CE gets enough current through the 1k5 resistor to run the damn thing.

I was thinking about this while trying to sleep and got up and tried a few things so it's back to bed (my roster gave a 4 day weekend)

Tomorrow I will try R-Type out and make sure it doesn't reset.

Also megadrive games to see if this can be hardwired in at all times.

Chip code:

#include <xc.h>
#include <pic16f628a.h>

// Config bits
#pragma config WDTE = OFF // Watchdog Timer disabled
#pragma config PWRTE = OFF // Power-up Timer disabled
#pragma config MCLRE = OFF // MCLR pin function is digital input
#pragma config CP = OFF // Code Protection disabled

#define wait_() while (PORTAbits.RA5 == 0) {;} // wait for RA5 high again
#define wait() while (PORTAbits.RA5 == 1) {;} // wait for RA5 low pulse

uint8_t send[3] = {0x31, 0xF0, 0xDF};

void init(void);

void main(void) {
init();

while(1) {

for (int i = 0; i < 3; i++){
wait();
PORTB = send[i];
wait_();
}

// All pins high-z
TRISA = 0xFF; // Set all pins of PORTA as inputs
TRISB = 0xFF; // Set all pins of PORTB as inputs
// Sleep MCU
SLEEP();
}

return;
}

void init(void) {
// Configure RA5 as INPUT
TRISA5 = 1;

// Configure RA0 as OUTPUT
TRISA0 = 0;
// CE PIN HIGH through 1.5k Resistor
RA0 = 1;

// Configure RB0 through RB7 as OUTPUT
TRISB = 0x00;
}

Edit: OK so having this connected does something to the way the controllers are polled and i get locked in master system mode. Also, aztec adventure screwed out again with the graphics and i couldn't get it good like I did lastnight. Opened it up and found both additional components besides the ROM were flapping about and i replaced and fixed those which didn't help. I am throwing the board in a box for now and putting this on hiatus :P

Author	Message
L10N37 Joined: 27 Jun 2020 Posts: 212	MD Fuhrer project, SMS PAUSE, stack pointer init, multi video mode DFO Posted: Thu Feb 22, 2024 1:11 pm
L10N37 Joined: 27 Jun 2020 Posts: 212	My new project using ATMEGA328P, my goodbye to 8bit MCU's as they are a bit boring and I want to move to 32bit. https://github.com/L10N37/MD-Fuhrer/tree/main Check it out, Thanks Raphnet for the stack pointer page. I rewrote this my own way to understand it a few years back which helped immensely as I just put my own version in notepad, made a bunch of notes of which pins toggle and ported it to a PIC16F628A which I chose a few years ago. It's perfect for this. It just sat in a drawer because I lost my kicad files for my SMS pin adapter. I devved on Model 2 VA1 JP/ PAL. JP wouldn't toggle 50/60hz, moved to PAL board. I think the 315-5660-10 was either bad on that pin or hard locked to 60Hz? The internal pull-up didn't exist, so it was 'floating' but stayed in 60Hz. It does NTSC443, PAL60, Straight PAL, Straight NTSC all with button combinations. SMS pause with button combo held a couple seconds, and stack pointer init on the PIC mentioned above. I don't know if I'll ever get around to PCB's etc. It uses a 5v mini relay to short the reset button and save settings on reset if you change any modes. JP / ENG is also on toggle with a button combo. Benefits: Cleans up the shitty composite of NTSC consoles. No rainbows anywhere, no banding. Full DFO, multi region. 50/60hz, correct refresh rate. Toggle Sub carrier for the modes. No invalid modes available. Well, other than PAL JP.

Jabberwocky Joined: 07 Apr 2021 Posts: 20	Posted: Sat Feb 24, 2024 1:52 am
Jabberwocky Joined: 07 Apr 2021 Posts: 20	I'm sorry I must ask, but why did you call it the Fuhrer?

segarule Joined: 23 Jan 2010 Posts: 439	Posted: Sat Feb 24, 2024 10:43 am
segarule Joined: 23 Jan 2010 Posts: 439	I think that Fuhrer=Leader. Im not sure.

L10N37 Joined: 27 Jun 2020 Posts: 212	Posted: Sun Feb 25, 2024 5:19 am
L10N37 Joined: 27 Jun 2020 Posts: 212	Yeah it's just german. Hitler baby. If anyone can help. My original stack pointer set up (late at night, after work) My version stupidly had 9 bits. Ignoring the last bit 8 as I was using binary not hex and assume the compiler would ignore that I would have sent 21 01 A1 25 B9 C7 I have no idea what this translates to when its sent down the cart bus, but all the games requiring stack pointer set up were loading. Good audio, no garbled graphics etc. The archived discussion is here: https://web.archive.org/web/20190403192608/http://www.smspower.org/forums/14084-... The correct bytes are now in my source code for the PIC chip. #include <xc.h> #include <pic16f628a.h> // Config bits #pragma config WDTE = OFF // Watchdog Timer disabled #pragma config PWRTE = OFF // Power-up Timer disabled #pragma config MCLRE = OFF // MCLR pin function is digital input #pragma config CP = OFF // Code Protection disabled #define wait_() while (PORTAbits.RA5 == 0) {;} // wait for RA5 high again #define wait() while (PORTAbits.RA5 == 1) {;} // wait for RA5 low pulse uint8_t send[6] = {0x21, 0x01, 0xE1, 0x25, 0xF9, 0xC7}; void init(void); void main(void) { init(); while(1) { for (int i = 0; i < 6; i++){ wait(); PORTB = send[i]; wait_(); } // All pins high-z TRISA = 0xFF; // Set all pins of PORTA as inputs TRISB = 0xFF; // Set all pins of PORTB as inputs // Sleep MCU SLEEP(); } return; } void init(void) { // Configure RA5 as INPUT TRISA5 = 1; // Configure RA0 as OUTPUT TRISA0 = 0; // CE PIN HIGH through 1.5k Resistor RA0 = 1; // Configure RB0 through RB7 as OUTPUT TRISB = 0x00; } Fairly simple, now shinobi is ok. The audio is good and it doesn't randomly reset. R-Type would reset sometimes. Basically randomly, but usually at boss fights. This was the only issue with the initial one, R-Type. I played around with this a lot but usually Aztec adventure has sprite corruption and the intro screen is a garbled mess, shinobi will have audio drop after a few seconds into stage 1 and random resets, depending what you send. Sticking 'by the books' above, aztec adventure (which was initially fine) is doing the graphical corruption. Decoding Ralphs code, which is a massive headfck because D0 is tied high perma and some pins that don't exist on his MCU (PORTB bit 6/7) are always set to 0 for bit 6 and 1 for bit 7, which I ignored. Also the fact the bytes are split between PORTC and PORTB because the MCU doesn't have an 8 bit bus available. (portD has bit 0/1 taken by RX TX for UART) He seems to present initially 0x12 then the read cycles start he sends again 0x12 Then through the read cycles the 'by the books' from the offical converter dump. 0x21 0x01 0xE1 0x25 0xF9 oxC7 Also, I don't think it can be a part of this project anyway. The EverDrive clone I have doesn't like this happening at boot. It's ok to boot to the menu but chaos in games if they load. Stand alone megadrive game cartridges seem to be fine though. So maybe hard wiring it to the actual console and not as part of an adapter is a no no. I am happy to give up for now. Just confused on Aztec Adventure being a cnt. I've wasted enough time on this :P Also, I did try using an MCU to sniff the 8 bit BUS using official pin adapter with the ROM, but readings varied too much. If 16MHz MCU can not read reliably using the same method as sending the data not sure how a 4MHz one can get these loading 100% of the time when wired in. Read outs: Waiting for power on 1 00000001 A1 10100001 1 00000001 E1 11100001 F9 11111001 C7 11000111 END OF CAPTURE Waiting for power on 1 00000001 21 00100001 1 00000001 E1 11100001 F9 11111001 C7 11000111 END OF CAPTURE Waiting for power on 1 00000001 21 00100001 1 00000001 A5 10100101 F9 11111001 C7 11000111 END OF CAPTURE Waiting for power on 11 00010001 A1 10100001 1 00000001 E1 11100001 F9 11111001 C7 11000111 END OF CAPTURE Simple capture code, right shifts PORTD captures one bit to the right shoving out RX, then sets TX to perma 1 (D0 tied high) and writes out final bit from PORTB (D7) into bit position 7. #define outputEnableHigh (bitRead (PINB, 1) == HIGH) void setup() { DDRD &= ~(B11111100); DDRB = 0x00; Serial.begin (115200); } void hang(){ hang(); } void loop() { TRYAGAIN: uint8_t capture[6]; bool captureD7[6]; Serial.println ("Waiting for power on"); while (bitRead (PINB, 4) == 0); // wait here until consoles powered on (digital pin 12 to VCC plane on console) for (int i=0; i<6; i++){ while (outputEnableHigh); captureD7[i] = bitRead (PINB, 0); capture[i] = PIND; while (!outputEnableHigh); } for (int i = 0; i <6; i++) { capture[i] = capture[i] >>1; bitSet(capture[i], 0); bitWrite(capture[i], 7, captureD7[i]); } for (int i = 0; i < 6; i++){ Serial.println(capture[i], HEX); Serial.println (capture[i], BIN); Serial.println (" "); } Serial.println (" END OF CAPTURE "); Serial.println (" "); while (bitRead (PINB, 4) == 1); // wait here until consoles powered off goto TRYAGAIN; hang(); //stopped using this as always had to reset }

segarule Joined: 23 Jan 2010 Posts: 439	Posted: Sun Feb 25, 2024 12:44 pm
segarule Joined: 23 Jan 2010 Posts: 439	Quote Yeah it's just german. Danke Quote Hitler baby. Im not nazi. Im just studied a bit of german.

L10N37 Joined: 27 Jun 2020 Posts: 212	Posted: Sun Feb 25, 2024 1:08 pm
L10N37 Joined: 27 Jun 2020 Posts: 212	segarule wrote Quote Yeah it's just german. Danke Quote Hitler baby. Im not nazi. Im just studied a bit of german. This definitely wasn't aimed at you, they called Hitler the Fuhrer.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Sun Feb 25, 2024 4:52 pm
	Just to be clear: using the work Fuhrer is likely to make people think of Nazi history, and this might upset some people. Use it at your own risk. SMS Power official position on Nazis is that they are bad. Thanks for reminding me of that lost forum topic; I've resurrected it from an old backup: https://www.smspower.org/forums/14084-PowerBaseConverterInfo And, since it seems not to be very clear (to me at least), this is a (not yet completed?) mod chip for a Mega Drive which seems to implement a few nice things: * Control pad control of region (Japan/Export) and speed (50/60Hz), with persistence * Stack setting like the original Power Base Converter, for better compatibility when using other such converter cartridges/Everdrive * Control pad for SMS pause button when playing SMS games Please correct any misunderstanding!

L10N37 Joined: 27 Jun 2020 Posts: 212	Posted: Mon Feb 26, 2024 12:47 am
L10N37 Joined: 27 Jun 2020 Posts: 212	Maxim wrote Just to be clear: using the work Fuhrer is likely to make people think of Nazi history, and this might upset some people. Use it at your own risk. SMS Power official position on Nazis is that they are bad. Thanks for reminding me of that lost forum topic; I've resurrected it from an old backup: https://www.smspower.org/forums/14084-PowerBaseConverterInfo And, since it seems not to be very clear (to me at least), this is a (not yet completed?) mod chip for a Mega Drive which seems to implement a few nice things: * Control pad control of region (Japan/Export) and speed (50/60Hz), with persistence * Stack setting like the original Power Base Converter, for better compatibility when using other such converter cartridges/Everdrive * Control pad for SMS pause button when playing SMS games Please correct any misunderstanding! It's not to offend anyone. Yes, Nazi's are bad. Not just region pad, these are tied together with encoder pad. You cut /separate these traces so they no longer 'agree' with each other. Now you can choose 60Hz master clock, PAL encoded @ 60Hz. PAL60. Full modes: PAL60 NTSC443 NTSC PAL Japanese / english toggle. The only unofficial type of mode I left in was normal PAL mode but you could select JP on this and get JP PAL. You can also pause the console by holding BTN1 + BTN2 + DN for a couple seconds. It will detect SMS controller vs Megadrive controller. It's not polished yet. The Atmega328P side of things is close to finished and just needs some more testing and stuff. I decided to implement the stack setting on a separate chip as I am out of I/O pins on the Atmega328P (nano/ uno for now + SI5351 dev board, until proper PCB is measured out and designed nicely) The dev board is fine @ 5v, has regulator and level shifting components. PCB would need 3.3v regulator. Clocks are fine @ 3.3v, i have a component here that can level shift all the way up to 100MHz fine, but it's not required. Console is happy with 3.3v clock out. So the board outputs NTSC / PAL Master clocks NTSC / PAL SubCarriers This is why you can get all those video modes. It really helps in NTSC Megadrives where they seem to do rainbow colour output all over the place. Mainly the white's you'll see it, and from what I've read online some will do really bad rainbow banding. I think this is the sub carrier derived from master clock through division in the VDP. It travels a long distance across the board, right past the main power input / 5v reg on model 2. So now you get clean composite in all modes. I did use 1.2k series resistors on what ever on D10 / D11 (I think 50/60Hz toggle and encoder mode toggle) because there was a little residual voltage on those pins when floating. The 50/60Hz was a full 5v VCC from an internal 1k pullup. It probably wouldn't hurt to connect these directly. The pause output needs to be connected directly. The reset / save settings (board saves modes on reset) which is A+B+C+START is done through a 5v mini reed relay. The reset circuit needs direct S/C 5v to GND (im sure it's through some protective resistors somewhere but i can't find them) and you just kill I/O pins pulling it to ground. This way the MCU just sends a high to the relay, the relay throws an internal switch which is equivalent to pressing the reset button. This would cover active high and active low reset circuits found on model1 / model 2. Now what I am confused about as mainly posted about on this thread, is the stack set up which I'd like to have as part of the board. There are 8bit atmel MCU's with way more pins, good price, but no dev board for them, hence, I moved the code across to the PIC16F627/628A. My first version as mentioned, booted every game requiring stack pointer set up 100% of the time. It was just that R-Type was resetting randomly. Since trying to fix it, It's just gotten worse. Where it stands, it should be sending the required bytes at boot but this interferes with some Megadrive games when using Mega EverDrive and Aztec adventures boots with graphical corruption. I'm also having trouble black-boxing the official adapter by capturing it's output and ignoring what's on the ROM. I can only catch the 0x25 if I instead switch it to catching bytes while OE is high (instead of low) and there's no consistency. I probably should hook up a logic analyser, but it seems pointless when the work has already being done. Some clarity on why Ralph sends that first byte would be good, and why I can't catch what it does on the BUS through my capture code with consistency as those were just the best captures out of handfuls. If anyone wants to try it out (without the stack pointer set up for SMS games, which is a separate chip) The combos should be A+START+ (left, right,down or up) for all 4 video modes. The source is pretty well commented. It's also easy to read, everything is in a function and it's just pin toggling. oh .. and JP/ENG toggle is A+B+ST Also, happy to change the name if i ever get around to polishing it and turning it into a proper kit. Lets just keep fuhrer as prototyping.

L10N37 Joined: 27 Jun 2020 Posts: 212	Posted: Mon Feb 26, 2024 4:17 pm
L10N37 Joined: 27 Jun 2020 Posts: 212	I got this stack pointer set up working. https://www.smspower.org/forums/18459-RTypeOnMegadrivePowerBaseConverter This page confused me, quote: "The RAM will be disabled if the byte read from $c000 has bit 4 set. However, the official converter contains a tiny Boot ROM which should prevent this from happening - the code in the ROM both initializes the stack pointer and writes $00 to $c000 (via the mirror at $e000)." However this blows it out to 10 bytes and didn't seem to work. Games glitch, aztec has graphical corruption. Shinobi sound disappears and resets very shortly into level one or hard locks. I can't see how this happens (what is quoted) I cut to the chase. I can drive the 8 bit bus, all 8 bits. I am not restricted to some instruction work arounds that involve having one bit tied high because I have only 7 pins to work with. LD SP, $DFF0 ; Load the stack pointer (SP) with the value $DFF0 {0x31, 0xF0, 0xDF}; I did listen to the comments about that being a better memory address than where they could land with hack around instructions. So far all good, no power and gnd on the PIC chip as the CE gets enough current through the 1k5 resistor to run the damn thing. I was thinking about this while trying to sleep and got up and tried a few things so it's back to bed (my roster gave a 4 day weekend) Tomorrow I will try R-Type out and make sure it doesn't reset. Also megadrive games to see if this can be hardwired in at all times. Chip code: #include <xc.h> #include <pic16f628a.h> // Config bits #pragma config WDTE = OFF // Watchdog Timer disabled #pragma config PWRTE = OFF // Power-up Timer disabled #pragma config MCLRE = OFF // MCLR pin function is digital input #pragma config CP = OFF // Code Protection disabled #define wait_() while (PORTAbits.RA5 == 0) {;} // wait for RA5 high again #define wait() while (PORTAbits.RA5 == 1) {;} // wait for RA5 low pulse uint8_t send[3] = {0x31, 0xF0, 0xDF}; void init(void); void main(void) { init(); while(1) { for (int i = 0; i < 3; i++){ wait(); PORTB = send[i]; wait_(); } // All pins high-z TRISA = 0xFF; // Set all pins of PORTA as inputs TRISB = 0xFF; // Set all pins of PORTB as inputs // Sleep MCU SLEEP(); } return; } void init(void) { // Configure RA5 as INPUT TRISA5 = 1; // Configure RA0 as OUTPUT TRISA0 = 0; // CE PIN HIGH through 1.5k Resistor RA0 = 1; // Configure RB0 through RB7 as OUTPUT TRISB = 0x00; } Edit: OK so having this connected does something to the way the controllers are polled and i get locked in master system mode. Also, aztec adventure screwed out again with the graphics and i couldn't get it good like I did lastnight. Opened it up and found both additional components besides the ROM were flapping about and i replaced and fixed those which didn't help. I am throwing the board in a box for now and putting this on hiatus :P

Forums

View topic - MD Fuhrer project, SMS PAUSE, stack pointer init, multi video mode DFO