MicroDuo if ever (2 x ATmega1284 system)

Discuss anything not related to the current Uzebox design like successors and other open source gaming hardware
User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: MicroDuo if ever (2 x ATmega1284 system)

Post by Jubatian » Tue Jun 25, 2019 6:22 pm

rv6502 wrote:
Tue Jun 25, 2019 1:48 am
Can you really pump 16bits transfers on a 1284 tho?

The extra bits can certainly be useful for other things such as sending interrupts or command/data protocol control flags but if it's synchronized burst transfers then only 8 wires are needed (or 8 resistors to be safe)

Code: Select all

ld r19, z+           
out PORT, r19        (nops)
ld r19, z+           in r19, PORT
out PORT, r19        st z+, r19
It most often would be synchronized bursts, but the catch is that it is difficult to synchronize so precisely that you can use the snippet above. By difficult I mean that it needs substantial amount of CPU clocks to get it, similar to the cycle-precise syncing in Uzebox interrupts. While if you had the following snippet for transfer (L-MCU => V-MCU):

Code: Select all

	lpm   r0,      Z+
	lpm   r1,      Z+
	out   PORTA,   r0
	out   PORTC,   r1
That works with a much looser sync, you can simply do an SBIC - RJMP spinner for that (SBIC on a pin by which the other MCU signals ready for burst). This results in two important things: You can do more individual transfers (such as individual tiles etc.) in the same amount of time, and that you can afford to actually have interrupts occasionally (there is less pressure on getting long bursts), for example to produce audio output on the L-MCU. I purposely used LPM here as it can also be a common scenario, deciding on that this would be the tightest sync I would be using.

There is an other issue with synchronizing, signal propagation delays in the MCU (there are related characteristics described in the MCU datasheet), which makes it less trivial.

So in overall I chose 16 bits for this, that during planning I realized that it fits OK among with the necessary control signals and all the rest, and it gives a significant performance benefit due to these matters. For sure there wouldn't be too many pins left on either MCU :)

rv6502
Posts: 23
Joined: Mon Feb 11, 2019 4:27 am

Re: MicroDuo if ever (2 x ATmega1284 system)

Post by rv6502 » Fri Jun 28, 2019 5:18 am

Makes sense.

resistors between the two MCUs to protect from accidental driving on both sides?


How about a 9th color pin that forces the output to white?
bst/bld could be used with that pin to add some kind of overlay for cheap, or quicker 1bpp output.

I'm also trying to figure out a cheap way to switch mode of one of the 8 bits transfer links on the game MCU side from communication to color override.

Allowing a mode where the GPU to do BG(s) and the logic MCU could do sprites, which would take less processing than BGs if timers are used. Leaving plenty for game logic. Bonus: it saves transferring the sprite updates.

How about 12 diodes and two GPIOs from the logic MCU to control each DACs respectively, output low to kill the color on that side, or held high to allow through.

When it kills the color on the Logic MCU side then the link can be used as normal.

And if it doesn't kill the color on either side then we get a MAX(R,G,B) function... I think...

The DACs would need to be adjusted for the forward voltage.

I'm sure I'm forgetting something...

rv6502
Posts: 23
Joined: Mon Feb 11, 2019 4:27 am

Re: MicroDuo if ever (2 x ATmega1284 system)

Post by rv6502 » Fri Jun 28, 2019 6:31 am

Also could we merge the gamepads into some other GPIO?

MOSI could control the latch (drop MOSI, raise it back up, no SPI clock, SD card sees nothing)
SPI clock pin could clock the gamepads as well as clock the SD card (MOSI is sending 0xFF to prevent latching the gamepads, that's a NOP for the SD card)
Two of the Logic MCU --1K--> GPU MCU comm lines could double up with
Gamepad --1K--> Logic MCU (input mode)

maybe a higher value would work too.

No harm as we can't clock in gamepads and talk to the GPU MCU in a practical way at the same time.

I think the shift chip inside the gamepads can handle 50Mhz so it's not like it'd risk entering a bad state when clocked at 9Mhz.

loop:
in r16, ; two lower bits: gamepad 0 and gamepad 1 data
ror r16
ror r18
ror r16
ror r20
dec r17
brne loop

8 cycles... The SPI hardware could do the clocking for us, just need to change to 1/8 from 1/2 , that's only SPCR:SPR0 that changes.

Not sure about the clock polarity of the SNES vs SD card.

And no idea what the 4 freed up lines would be used for but it's more lines for other fun stuff.

User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: MicroDuo if ever (2 x ATmega1284 system)

Post by Jubatian » Fri Jun 28, 2019 7:06 pm

Wow, quite some ideas there!
rv6502 wrote:
Fri Jun 28, 2019 5:18 am
How about a 9th color pin that forces the output to white?
bst/bld could be used with that pin to add some kind of overlay for cheap, or quicker 1bpp output.
I don't see too much point in doing that as I already have a 2.25 cycles / pixel 1bpp mode with arbitrary FG / BG colour for each scanline. That's up to some 400 pixels width! You could only do better than that by clocking pixels out using UART in SPI master mode (2 cycles per pixel I think), but that again would be fixed colours. Without that going higher in resolution than 2.25 cycles / pixel is not possible as you need loads and jumps, which enforce some 3 clocks wide pixels. Primarily this 2.25 cycles / pixel mode is designed to go along with the 4.5 cycles / pixel 4bpp mode (for a similar effect to mixing high-resolution text and Multicolour on Commodore 64).
rv6502 wrote:
Fri Jun 28, 2019 5:18 am
Allowing a mode where the GPU to do BG(s) and the logic MCU could do sprites, which would take less processing than BGs if timers are used. Leaving plenty for game logic. Bonus: it saves transferring the sprite updates.
This could be interesting! I am envisioning something along the lines of Mode 72 for such, whether it was possible to get the L-MCU preparing a scanline with sprite data, which then can be transferred and merged onto the background in the V-MCU. The greatest benefit would be RAM as otherwise this setup is a freaking powerhouse, to generate a normal Uzebox-style tiled mode, you have about 3-4 times more CPU. The most often you would run out of RAM before hitting the blitting bottleneck, especially if you wanted all the graphics to be loaded from SD. Which you would have to keep in the L-CPU's RAM as well to blit sprites. So if such a mode could be devised, that would save RAM (as background would only have to be placed on the V-CPU). CPU not so much since such a mode takes away all the display frame time with no frame drop (30FPS) option.

I will definitely look into this, without hardware mods. We certainly have the transfer bandwidth, the greater unknown being whether it was possible to code such on the V-CPU.

SPI, I am a bit uncertain on this one. I purposely chose the way Uzebox does it as it allows reusing the programmer pins to communicate with the SD card, and it works quite fine. The SD card otherwise is a real mess, giving lots of headache even when interfacing the SPI RAM on Uzebox. I wouldn't really want to share at least the MISO (which the card can affect) with anything.

Gamepads are fine scanned slow, in the Uzebox kernel, it is normally a tightly timed code, however in Flight of a Dragon, the new bootloader, and other kernel experiments, I set them up to be clocked from the HSync interrupt. This allows these programs to work with wireless SNES controllers (at least as it was reported, they are apparently slow). There are only a few bits to clock in, so no real latency. On the MicroDuo, I would similarly add the code to the L-CPU's audio engine. So with them I am also a bit reluctant on sharing, due to the uncertainties related to those wireless SNES controllers (such as even whether they could be messed up by "foreign" data on their lines from the SD card when communicating with the SD card).

Otherwise it might be interesting to experiment with using the SCK and MOSI for other things beyond the SD card (when the SD's Chip Select is high), but again, the programmer could be in the way. Probably not that much like I envision, though, and they could be used for some things. Maybe to communicate with an alphanumeric LCD panel, that could be a fun optional item only needing the out direction :)

Protection resistors, definitely not a bad idea of course if you worry about getting them driving each other! I purposely plan towards fixed directions though. The 16 lines always L-CPU => V-CPU, communicating back data would be slow bit banging by the few control signals (rare utility, and this case I would say better be safe than sorry). So the software provided with the MicroDuo would be designed to minimize the chance of such happening even if you built the most bare-bone minimalistic HW for it.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest