Start » Forum » MSX Talk » Development » Controlling MSX cartridge from Raspberry Pi GPIO ports

Controlling MSX cartridge from Raspberry Pi GPIO ports

Pagina 1/2
| 2

Door seanyoung

Resident (60)

afbeelding van seanyoung

26-10-2019, 17:42

Hello. I'm writing some code to control the GPIO ports of a raspberry pi so I can program a MSX cartridge. The PWM can generate the 3579545Hz clock. Now I want to to set the address/data and do a memory write.

From software the gpio ports can be controlled very precisely.

  1. What duty cycle should the clock be? 20%? 50%?
  2. Is memory write detected on rising edge of the clock, or lowering edge
  3. How many nanoseconds before and after that event should the address/data/WR/Slot select/etc be set?

For this to work I'm writing a little linux kernel driver which busy loops the raspberry CPU with interrupts off.

Thank you

Aangemeld of registreer om reacties te plaatsen

Van poepoog

Supporter (2)

afbeelding van poepoog

26-10-2019, 17:50

Be very careful: The Raspberry is 3.3 volt device so you will need logic level converter to interface with 5.0 volt devices like the MSX... Nishi

Van seanyoung

Resident (60)

afbeelding van seanyoung

26-10-2019, 19:22

Thanks, good point. I had not thought about that. I'll order some..

Van zPasi

Champion (499)

afbeelding van zPasi

26-10-2019, 21:08

What are you trying to do? For what you need the 3.58 MHz clock?

For example, if you're making an I/O-cart (that will be used by IN / OUT instructions), you'll just wait signals /IORQ and /RD or /WR to go low. You also could get the clock from the slot, but for what?

BTW: If you're making an I/O-cart, remember to set /BUSDIR low when writing to DATA-pins. If you don't, your circuit will work on some simple MSX, but burn on more advanced MSX.

About timings, I don't know, but you'll find more info on MSX Assembly Pages

Van seanyoung

Resident (60)

afbeelding van seanyoung

26-10-2019, 23:55

I'm trying to program an SCC from a raspberry pi, no MSX involved. So I need a clock etc.

So the SCC has a glitch in channel 4 and 5 which I haven't been able to reverse engineer by programming an SCC from an MSX and then attaching a logic analyser to the sound out pins. There was random behaviour happening. I'm hoping by controlling the power on of the SCC and programming at predefined clock cycles, I can have reproducible test cases and from that figure out how the glitch works.

Van NYYRIKKI

Enlighted (6091)

afbeelding van NYYRIKKI

27-10-2019, 06:39

Information about signal timings can be found from Wiki-pages: https://www.msx.org/wiki/MSX_Cartridge_slot#Chronograms

There is some talk about the ch4/ch5 problem here:
https://www.msx.org/forum/development/msx-development/scc-so...
... and a lot of talk about other SCC glitches here:
https://www.msx.org/forum/development/msx-development/pcm-pl...

Van zPasi

Champion (499)

afbeelding van zPasi

27-10-2019, 10:57

seanyoung wrote:

I'm trying to program an SCC from a raspberry pi, no MSX involved. So I need a clock etc.

So the SCC has a glitch in channel 4 and 5 which I haven't been able to reverse engineer by programming an SCC from an MSX and then attaching a logic analyser to the sound out pins.

"No MSX involved" but then "reverse engineering by programming an SCC from an MSX". I'm still not following you. Are you emulating an SCC in a Raspberry? But not connecting that to an MSX, but something else? And are you using the logic analyser on MSX or on Raspberry, or both?

But as discussed before (see NYYRIKKIs links) that glitch may be SCC normal behaviour.

Van rderooy

Paladin (686)

afbeelding van rderooy

27-10-2019, 12:05

You know the MSXPiHat right?
https://www.msx.org/news/hardware/en/make-a-raspberry-a-real...

Van NYYRIKKI

Enlighted (6091)

afbeelding van NYYRIKKI

27-10-2019, 12:40

Pasi: What Sean is trying to do here is to find out what really happens inside the SCC when these glitches appear. On MSX it is extremely hard if not impossible to get the chip in cycle accurate sync with the computer because even NOP on MSX takes 5 cycles. How ever this is not a big problem with modern, more beefy CPU like ARM in RasPi, so it is not a bad idea to build MSX slot to such computer for doing this kind of debug and then connect SCC cartridge to that slot. This kind of setup in future can be useful for debugging other MSX hardware as well.

Getting an idea of on what clocks these problems happen exactly, why and what kind of glitch can be recorded from output can help to improve the emulation and MAYBE even make it possible to write better music software that can hide these problems better once it is properly documented why they happen, what exactly they are related to and what is the output when these glitches trigger. ATM pretty much all that we know is that "sometimes something goes wrong with shared sample RAM read that causes crap to be output from DAC"... and that is not very technical definition.

Van Grauw

Ascended (10820)

afbeelding van Grauw

27-10-2019, 15:27

seanyoung wrote:

So the SCC has a glitch in channel 4 and 5 which I haven't been able to reverse engineer by programming an SCC from an MSX and then attaching a logic analyser to the sound out pins. There was random behaviour happening. I'm hoping by controlling the power on of the SCC and programming at predefined clock cycles, I can have reproducible test cases and from that figure out how the glitch works.

Oh that’s nice! Looking forward to your findings!

Van seanyoung

Resident (60)

afbeelding van seanyoung

27-10-2019, 21:53

NYYRIKKI wrote:

Pasi: What Sean is trying to do here is to find out what really happens inside the SCC when these glitches appear. On MSX it is extremely hard if not impossible to get the chip in cycle accurate sync with the computer because even NOP on MSX takes 5 cycles. How ever this is not a big problem with modern, more beefy CPU like ARM in RasPi, so it is not a bad idea to build MSX slot to such computer for doing this kind of debug and then connect SCC cartridge to that slot. This kind of setup in future can be useful for debugging other MSX hardware as well.

Getting an idea of on what clocks these problems happen exactly, why and what kind of glitch can be recorded from output can help to improve the emulation and MAYBE even make it possible to write better music software that can hide these problems better once it is properly documented why they happen, what exactly they are related to and what is the output when these glitches trigger. ATM pretty much all that we know is that "sometimes something goes wrong with shared sample RAM read that causes crap to be output from DAC"... and that is not very technical definition.

That's it exactly. :-)

The MSX PiHat seems like a great idea.

Pagina 1/2
| 2