Search options (Page 4 of 7)

Right now I can't locate SPI1_SCK on the Pin Assignment table, but the other pins are broken out.  I haven't had any luck with software yet.  I tried btmcmahan's library in slave mode using the example code, but nothing happens (I was using an Arduino as the master).

Thanks, I may look into this some time.

Great to hear you're set up in your new place and on board for the project.

I suspect you're right that Arduino code will be more efficient that Teensyduino code, but I have to agree with friendofmegaman that you're going to be very pushed for cycles, especially using an interrupt and doing a serial write straight away.

Do you mean converting CLK, D0, D1, HS, and VS to serial data?  Do you plan to send this data to a microcontroller, or are you connecting the DMG to the PC through something else?

You might want to use this version of the display code which I've modified to use Pygame instead of Pylab.  Pylab was extremely slow here...

#!/usr/bin/python
#author: friendofmegaman, rvan
#Display captured frame data on the PC.  Expects a 0x1E00 header and four
#pixels per byte.  Uses pygame, which is faster than pylab's scatter.

import pygame
from pygame.locals import *

upscale = 2

width = 160
height = 144

grey = []
grey.append((224,248,208))
grey.append((136,192,112))
grey.append((52, 104, 86))
grey.append((8, 24, 32))

fd = open('/path/to/screen.bin', 'rb')
data = fd.read()
fd.close()

frames = data.split('\x1E\x00')
print len(frames), 'frames'

class Pixel:
    x = 0;
    y = 0;
    def __call__(self, col):
        for upy in range(upscale):
            for upx in range(upscale):
                window.set_at(((self.x)*upscale+upx,
                               (self.y)*upscale+upy), grey[col])
    
        self.x +=1
        if self.x==160:
            self.x = 0
            self.y +=1

pixel = Pixel()
window = pygame.display.set_mode((width*upscale, height*upscale))

for frame in frames:
    # First and last frames can be smaller than that (because there's small
    # chance we start capture right at the beginning of the frame)
    if len(frame)!=5760:
        continue

    for y in range(144):
        for x in range(160):
            bit_offset = y*320+x*2
            array_offset = bit_offset/8
            byte_offset = bit_offset%8

            byte = ord(frame[array_offset])
            px = (byte>>byte_offset)&0b11
            pixel(px)

pygame.display.update()

quit = False
while not quit:
    event = pygame.event.wait()
    if event.type == pygame.QUIT or event.type == KEYDOWN and \
    event.key == K_ESCAPE:
        quit = True

Quite impressive, both your setup and your video.  I'm curious how you captured the video from the Game Boy Camera.  Did you use a Game Boy Advance with a TV adapter?  Also, how do you find using the NES pads with your fingers?  I've always used my thumbs for LSDJ and other things on the Game Boy and imagine that using fingers would be slightly awkward (for me, at least).  But then again, perhaps I'm simply not used to it.

Thanks for your answers.  I look forward to reading your full write-up.  I have looked at a number of Z80 systems, both commercial kitsets and hobbyist builds, with eventual plans to building one myself.  What sets your design apart is the use of the Propeller as the GPU.  I'm not especially well-versed in Z80 graphics architecture (other than the Game Boy's, which I am passingly familiar with), but I would like to know about the interface between the Z80 and the Propeller.  Does the Z80 see the Propeller purely as a memory-mapped peripheral?

As for selling this as a commercial product (if you are still trying to), I think you are in for a hard task. Projects like this are mostly of interest to hobbyists (like ourselves) who like to build things rather than buy them, although you might have some success selling this as a kitset.  There are a number of kitsets out there for the Z80, but I have not seen many targeted towards video games as opposed to general-purpose microcomputer systems (although I haven't been looking for them specifically).  On the other hand, there are many, many video game console kitsets that are not specifically Z80-based.  This means that you are entering a more-or-less saturated market and will have to come up with a unique selling point.

The EMS 64 USB Carts do indeed use a standard Mini-USB cable.  You might have been reading about the older non-USB carts, which plugged into a flasher which connected to the parallel port instead.

It's worth adding that while the cart will work on later Game Boys, it is still a Game Boy (not GBA) cartridge, so you won't be able to use GBA games/software.

I just want to step in to second this.  Calling Lacklustre's ems-flasher "a mess" hardly does it justice.  I don't know what issues materiaxmedica had, but I have used ems-flasher on Linux for a while with no issues.  (Note that it must be installed setuid root; I'm not sure if the documentation mentions this explicitly.)

I understood that the point of an internal prosound was that it replaced the stock output.

The prosound does sound quieter through headphones than the stock output, but is still plenty loud enough, and I regularly use headphones with my prosound output quite happily.  Comparing stock and prosound side-by-side now and listening to Kirby's Dream Land, the main difference is substantially less hiss from the prosound output.  This is probably the biggest benefit you will get for listening to games.  My prosound is RCA post-pot.  You will certainly want post-pot for use with headphones, by the way.

Disappearing lines of pixels are not uncommon as the LCDs age, and can be fixed by the soldering iron method.  I have done so successfully, but have also had one screen which seemed beyond repair.  You will probably be in luck.  Take it very slowly.

As for the other issues, first of all back up your saves.  I suspect that some kind of power issue (most likely dying batteries) is responsible.

Some things to try:

• Replace the batteries

• Clean battery contacts / inspect for corrosion

• Try an AC adapter

• Clean your cartridge slot and contacts on the cartridge (probably not responsible for the slowdown, though)

• If possible, try your LSDJ cartridge in another DMG

• If you have a backlight, try disconnecting it

• Check your SRAM battery (just in case)

If none of these work, or especially if disconnecting the backlight solves the issues, the answer may be a bad power regulator board.

This may just be me, but I would have appreciated if you'd said up-front that you were planning this as a business endeavor.  Nonetheless, I am interested to see what you come up with.

This looks quite interesting.  I would enjoy reading a detailed write-up if you are planning on making one.  I assume you are storing sprite data on the EEPROM and that this is copied to the Propeller's internal RAM on boot?  If so, is the Z80 involved in this process, or does the Propeller access the EEPROM directly?  Also, does your Cartridge ROM also contain your bootloader, or do you have a separate boot ROM?  I am aware this is off-topic for this thread, so you may wish to start a separate thread about this project.