Demo Vision

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderator: Moderators

Fiskbit
Posts: 891
Joined: Sat Nov 18, 2017 9:15 pm

Demo Vision

Post by Fiskbit »

I posted a page on the wiki for the Demo Vision based on my findings reverse engineering the firmware software. I'm reasonably confident in all of the information on there, but as I don't have access to the hardware or high quality images of both sides of a Demo Vision PCB, there are various mysteries left. I reached out to Chris Covell to see if he could fill in the blanks, but unfortunately, he doesn't own one anymore. He was kind enough, though, to send the images he took of it, which might help at least a little bit. These are higher quality than what's on his site. I've attached them below.

Here are the known unknowns I can think of:

- /IRQ: I don't know exactly how the IRQ works. It looks like it's triggered at the Game Boy refresh rate during Game Boy vblank somehow, and it doesn't require an ACK, but the IRQ handler only takes about 0.75 ms, which is shorter than Game Boy vblank, so it's not just vblank.
- DIP switches: There are 6 DIP switches, with 3 definitely CPU-readable. I don't know which 3 in what order, nor do I know if the other 3 connect to anything at all.
- CHR RAM wiring: Since each screen buffer is 2 CHR-RAMs, I imagine the bitplanes are split between chips so that a single sliver can be written into both simultaneously, but I don't know this for a fact. I also don't know whether PPU /WR is hooked up, so I don't know if the PPU can write into the active buffer.
- OUT0: This controls Game Boy power or reset, or something like that. It looks the power switch does have wires to it, so I suspect it does in fact control power.
- Mirroring: I don't know how the CHR and PRG are mirrored up; that is, what banks will show what mirrored content (or open bus).

There's probably other stuff, but that's what comes to mind for now.
Attachments
IMG_0921.JPG
IMG_0927.JPG
IMG_0933.JPG
IMG_0928.JPG
Fiskbit
Posts: 891
Joined: Sat Nov 18, 2017 9:15 pm

Re: Demo Vision

Post by Fiskbit »

Apparently there is a Demo Boy II (and presumably I?) that looks identical to the Demo Vision, down to the enclosure, but the PCB is green. Very low-res photos and an IC list are available here. For preservation's sake, I'm including the IC list below.

Code: Select all

   Demo Boy II Integrated Circuit Parts List

   -----------------------------------------



Part Number     Category              Board Location

-----------     --------              --------------



Nintendo MMC5A  Memory Mapper(100pin) U42

AMPAL20L10      PAL                   U46

RP2A03G         NES CPU(40pin)        U34

RP2C02G-0       NES PPU(40pin)        U33

27C64           EPROM                 U32,U47

Sharp LH5116    RAM                   U38

Sharp LH5168    RAM                   U13,U16,U25,U28,U39

74HC04          logic                 U37,U40

74HC08          "                     U41

74HC32          "                     U44

74HC139         "                     U29

74HC157         "                     U1,U4,U5,U6,U9,U10,U12,U19

74HC161         "                     U35

74HC164         "                     U2,U3

74HC197         "                     U17,U22,U24,U31,U36

74HC368         "                     U50

74HC373         "                     U45

74HC541         "                     U7,U8,U14,U15,U20,U21,U26,U27,U49

74ALS1035       "                     U100
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: Demo Vision

Post by Ben Boldt »

A couple of interesting observations about the MMC5 in your photo:
  • AVcc and AGnd (Analog power pins for expansion audio) are being powered, though no visible connections to pins 1, 2, 3, or 100. It seems unlikely that they would power this part of the chip without at least grounding pin 1 (audio amplifier input).
  • pin 81 ( :shock: ) visibly connected to pin 80 (GND). We have no clue whatsoever what pin 81 does. It is normally what we presumed to be a floating input in MMC5 cartridges. Here, they seem to have grounded it.
I would LOVE to see the traces with this chip removed... Not likely, I know.
pin 81.png
Fiskbit
Posts: 891
Joined: Sat Nov 18, 2017 9:15 pm

Re: Demo Vision

Post by Fiskbit »

Looking at the IC list and the board, I suspect this system has 8 KB of RAM at CPU $0000-1FFF.

I'm looking into finding people who can get higher quality images of the front and back of the board and Game Boy wiring. Maybe we'll get lucky and someone will be willing to poke around with a multimeter to see what connects to what, or send one of us a board so we can do it. I don't expect people to be willing to desolder the MMC5!
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: Demo Vision

Post by Ben Boldt »

With experience, you can safely remove that chip and reinstall it without any damage. It would be highly cool to remove all of the chips from one of these and make new boards, wouldn't it?? It appears that all of the chips are obtainable. I guess I am not sure what is on the lower board (just a copy of the top board?) or what goes into the gameboy itself, but if they are all common parts, then we can replicate these.
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: Demo Vision

Post by calima »

MMC5 obtainable? Or for that matter, the Gameboy chips?

IIRC retrousb already had a GB-on-NES product.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Demo Vision

Post by lidnariq »

Ben Boldt wrote: Mon May 02, 2022 8:46 am I guess I am not sure what is on the lower board (just a copy of the top board?)
The second picture appears to be a copy of the top board. Supposedly these sometimes existed as two kiosks side-by-side.
or what goes into the gameboy itself
Only the 10-conductor cable. Six are for capturing video (Pixel1=LD1, Pixel0=LD0, Pixel clock=CP, Hsync=ST+CPL, Vsync=S), a tap for audio output and ground, plus two more to power it.
Attachments
IMG_0933_annotated.JPG
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: Demo Vision

Post by Ben Boldt »

calima wrote: Mon May 02, 2022 10:37 am MMC5 obtainable? Or for that matter, the Gameboy chips?

IIRC retrousb already had a GB-on-NES product.
Yes, MMC5 is obtainable. If we were to make up to 10 of these (i.e. 5 dual units), it is an acceptable sacrifice. More than that, I think we shouldn't. The MMC5 does not appear to be doing a whole lot; it is set up for a static extended attribute table that could probably be reasonable to replace with a CPLD.
Fiskbit
Posts: 891
Joined: Sat Nov 18, 2017 9:15 pm

Re: Demo Vision

Post by Fiskbit »

I found this project with a goal similar to the Demo Vision that taps the same signals. I've been trying to figure out how the vsync signal works on GB, wondering if the IRQ signal could just be that (inverted). According to this guy, it sounds like it's only asserted briefly around the end of vblank, but it's not clear to me when this is relative to the start of the screen data. Is there any time for the NES side to enter the IRQ handler and swap buffers before the screen data begins?

Regarding the second PCB, it should be an identical board, and there are supposedly no logical connections between them.
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: Demo Vision

Post by Ben Boldt »

I have been thinking about this and I have a couple of crazy ideas.

First of all, as far as we know, the MMC5 is being used only for extended attributes, and those attributes are 100% static, only initialized and never change. I don’t think it is even doing any memory mapping other than maybe putting W-RAM at $6000-7FFF.

In theory, couldn’t you do static extended attributes with a big ripple counter connected to PPU/RD? Then the counter outputs just run directly the address of an EPROM? You could program the EPROM with the static attributes, find a way to reset the count each v-blank. I don’t think sprites are even used either. That seems like it would work!

Then I start thinking, why can’t this all be done in a cartridge? Of course what they did with the dip switch on the controller I/O wouldn’t be possible, but that’s just a small hack for later. Take away the CPU, PPU, everything that makes it a Famicom, you are left with some RAMs, ROMs, 7400 logic, and this counter instead of an MMC5. That sounds doable in a cartridge, especially if using surface mount chips on both sides, or just replacing all that logic with a CPLD.

Imagine a cartridge, with a ribbon coming out, connected to a Gameboy, acting exactly like that old Toys R Us kiosk. Now that would be cool.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Demo Vision

Post by lidnariq »

Ben Boldt wrote: Mon May 02, 2022 6:51 pm In theory, couldn’t you do static extended attributes with a big ripple counter connected to PPU/RD? Then the counter outputs just run directly the address of an EPROM? You could program the EPROM with the static attributes, find a way to reset the count each v-blank. I don’t think sprites are even used either. That seems like it would work!
Yes, but you could also just keep track of the attribute table address and use it for banking purposes. Latch some subset of PPU A0-A5,A10-A11 (A6-A9 are always 1 during attribute fetches) on name/attribute table fetches and because the fetch cadence grabs the attribute table after the name table, you can switch pattern tables accordingly.
User avatar
aquasnake
Posts: 515
Joined: Fri Sep 13, 2019 11:22 pm

Re: Demo Vision

Post by aquasnake »

It seems that the 3rd ntram of mmc5 can be used as a buffer to connect the VRAM of an other game console, and then mirror the running screen to nes

This 3-rd ntram design needs to use a dual port RAM

Another similar idea is the Pi-PU project.
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: Demo Vision

Post by Ben Boldt »

aquasnake wrote: Thu May 12, 2022 4:19 am It seems that the 3rd ntram of mmc5 can be used as a buffer to connect the VRAM of an other game console, and then mirror the running screen to nes

This 3-rd ntram design needs to use a dual port RAM

Another similar idea is the Pi-PU project.
Would you please elaborate on this; I am not understanding what you are saying. Are you implying that the DemoVision is using the MMC5's built-in RAM as a nametable? Where would the pattern tables go, to store the actual bitmap graphics?

With the available DemoVision ROM, you can actually run it in an emulator; it works and just has garbage where the Gameboy graphics would go. From this, you can see that the MMC5's internal RAM is being used as an extended attribute table. This is being used for 8x8 palette granularity and setting up 3 separate CHR banks for the gameboy graphic area. (i.e. The MMC5's internal RAM is not being used as a nametable for the DemoVision.)
User avatar
aquasnake
Posts: 515
Joined: Fri Sep 13, 2019 11:22 pm

Re: Demo Vision

Post by aquasnake »

Ben Boldt wrote: Thu May 12, 2022 10:30 am
aquasnake wrote: Thu May 12, 2022 4:19 am It seems that the 3rd ntram of mmc5 can be used as a buffer to connect the VRAM of an other game console, and then mirror the running screen to nes

This 3-rd ntram design needs to use a dual port RAM

Another similar idea is the Pi-PU project.
Would you please elaborate on this; I am not understanding what you are saying. Are you implying that the DemoVision is using the MMC5's built-in RAM as a nametable? Where would the pattern tables go, to store the actual bitmap graphics?

With the available DemoVision ROM, you can actually run it in an emulator; it works and just has garbage where the Gameboy graphics would go. From this, you can see that the MMC5's internal RAM is being used as an extended attribute table. This is being used for 8x8 palette granularity and setting up 3 separate CHR banks for the gameboy graphic area. (i.e. The MMC5's internal RAM is not being used as a nametable for the DemoVision.)
Synchronization requires a large amount of data temporary storage. Generally, 8K pattern, 2K ciram (ntram) and 32 byte palette index need to be written. However, according to my test of the save state function, using CPU to hijack NMI to realize self writing requires about 1 frame per 4KB, which requires 3-4 frames. Now this method will seriously affect the display efficiency.

The appropriate application is to store static data in CROM, only bank switching without temporary storage. Switch the pattern table and name table in bank mode, and write only a small amount of attribute table and palette index, Only 64 + 32 bytes need to be added to each frame(NMI)

This is my wild guess. Using the save state function, the arbitrary jump of programs and graphics (but not sound) has been realized. Therefore, it is also possible to realize the intervention of any other graphics (1 full screen) data
seijurou
Posts: 9
Joined: Tue May 24, 2022 3:42 am

Re: Demo Vision

Post by seijurou »

Hello all.

I have both systems, if any pic is needed please let me know.
Post Reply