Overlay update

[rgalland]

It is now time to add the overlay to the project and include several gates not present in the original schematics.

First items I can thing of adding are but not limited to:

• [x] BOOT ROM
• [x] HRAM
• [x] OAM
• [x] Wave RAM

[msinger]

Can we clean up a bit first? I would like to export a PDF and link it in the README.md so that people can open the schematic without the need for installing KiCad. I suspect the wave diagrams that are placed outside of frame to mess up a printout of the PDF. The pages can shrink because of that. Can we move them to another sheet? I think it would make sense to have those diagrams outside of the schematic. We could make a documentation folder and put HTML documents in there that contain the diagrams. The wavedrom website states that the rendering engine can be embedded in HTML. It is java script. This way, we can store the source of the diagram and do not have to commit any image files. What do you think?

[rgalland]

I moved the diagram data outside of the frames to help with exporting to pdf. I think we can now also removed the mistakes from the original schematics since they have been addressed. I like the idea of the documentation folder to store the diagram data.

[msinger]

I printed it out. It seems to work with the diagram data outside of frame. I was afraid that this text would be hidden in the PDF and mess up the scaling of the sheets when being printed. But the printout looks good. Even on A4, the font is big enough to be still readable. Only thing that is a bit unfortunate is that the green and red background colors of the boxes are making the yellow font of the labels unreadable. At least when printed in color. I haven't tried how it looks in black&white. I don't know what to do there, I like your idea of knowing where the IO pins are and which sheets have sub sheets. Maybe it works when we make the color much lighter?

Yes, we don't need the comments about the mistakes anymore.

[msinger]

I just added the overlay file. I remember I made minor changes when I created the web browser map with it. I had to move some texts into the "labels" layer. They have been on the wrong layer and thus didn't show up on the map. But I didn't change any wires or cells or texts. Those should all be original.

Can you try if you can successfully open it with Inkscape when you place the two die shot files in the same directory where the overlay is in the repository? I added a .gitignore for them, so they don't get accidentally added.

The first file is the brownish die shot that Furrtek used: https://siliconpr0n.org/map/nintendo/dmg-cpu-b/single/nintendo_dmg-cpu-b_mz_mit20x.jpg The second one is this grayish/blueish one: https://siliconpr0n.org/map/nintendo/dmg-cpu-b/single/nintendo_dmg-cpu-b_s1-1_mit20x.jpg

[rgalland]

Inkscape was complaining for some reason as it could not find link to the first image but it working now.

[msinger]

Oh no, I know why. My file has an underscore between "cpu" and "b". The file on siliconpr0n now has a dash/minus sign between them. They must have changed that at some point after I downloaded the file; or maybe I downloaded it from somewhere else back then. We should change that to a dash. What have you done to fix that?

[rgalland]

I did a quick copy and paste in the overlay using the actual file name. I will soon commit the first cells added à round the Hram so that you can have look. I generated the cell names with your program.

Obtenir Outlook pour Androidhttps://aka.ms/AAb9ysg

---

From: Michael Singer @.> Sent: Sunday, July 10, 2022 2:35:21 PM To: msinger/dmg-schematics @.> Cc: rgalland @.>; Author @.> Subject: Re: [msinger/dmg-schematics] Overlay update (Issue #149)

Oh no, I know why. My file has an underscore between "cpu" and "b". The file on siliconpr0n now has a dash/minus sign between them. They must have changed that at some point after I downloaded the file; or maybe I downloaded it from somewhere else back then. We should change that to a dash. What have you done to fix that?

— Reply to this email directly, view it on GitHubhttps://github.com/msinger/dmg-schematics/issues/149#issuecomment-1179720530, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGPQBX6PALHLTSJDCQIYGRLVTK7QTANCNFSM52457OHQ. You are receiving this because you authored the thread.Message ID: @.***>

[msinger]

Looks good. Did you figure out which tool he used to draw the wires, or did you just copy one of the small orange pieces? Also, is there a reason for naming the bottom two cells something with Bxxx instead of Axxx? There is also a misplaced or mislabeled cell in the top left "R" column called SETY. I was hoping we could fix this and make columns consistently starting with the same letter. Maybe there were some other too that I don't remember.

[rgalland]

Yes, I wasn't thinking straight when giving the names. Yes, it should have been consistent so now I'm changing them to Axxx. I changed SETY and SAHA as well which was only a couple of cells up from SETY to ROSU and RONU.

[rgalland]

I only copied and pasted the orange wires. I will need to figure out how to draw the lines properly later on.

[rgalland]

Do you have any idea of a more relevant name for BUKE? It is almost like a data latch signal. What do you think?

[msinger]

I don't know about BUKE. When naming the pins of the CPU symbol, I named it LATCH_CLK, because I was thinking it is the only clock like signal that does not have a complementary counterpart, like the other eight clock inputs of the CPU. But I wasn't thinking far enough, because latches also need an inverse. So I don't know what it is used for really. It flips at the same time as LAVO when there is a read operation going on. So LAVO latches the data that comes in from external data bus. Maybe the CPU also latches their data lines at the same moment. So I would be fine with that if you call it something with DATA_LATCH, like you suggested already.

[rgalland]

@msinger , can you have a look at the boot rom buffer I created and let me know if it matches what you can see. There is a weird transistor that pulls up the input when it is not selected, otherwise, it inverts the rom bit and buffers it 4 times. It might make more sense to have the whole 8 bits instead of just one and have it as 1 symbol.

[msinger]

The buffer you created... Do you mean "ZERY?" (/BOOT_CS)? You could route that /BOOT_CS signal into the /OE input. Or do you want to make OE high-active? But then we should be consistent and only draw the first ZERY inverter, like we do with the flip-flops that have complementary clock inputs. I thought maybe we could mention these hidden inverters for the flip-flops in comments next to the flip-flops. Or in this case, next to the ROM symbol.

This is what I see:

Yes, the one transistor that pulls the ROM bit high is weird. But I don't know the upper part of the ROM. Maybe the internal data line needs to be pre-charged with a 1. Maybe the ROM matrix only contains NMOS transistors and is not capable to pull the data line high. This way, it is all more compact. When output gets enabled (ZERY=1) then the data line keeps its high state due to the capacitance of the wire. Only when there is an NMOS placed in the matrix above that is enabled by the selected addresses, the data line gets pulled low. But this is just a guess.

I don't understand what you mean in the last sentence. I feel I miss some context. :)

Do you have an idea what those SPARE cells are, that I wrote about in my last mail?

Again, you don't have to take care of the issues I post, if you want to spend time on your other projects. It's fine. :)

[msinger]

This should be equivalent, I think:

[rgalland]

Yes, the equivalent circuit is ok. Is it alright if I let you update the cmos_cells project? Have you also decoded the IO buffers for the HRAM, WAVERAM and OAM? In fact the WAVERAM IO buffer is different to the other 2.

[msinger]

Yes, you're right. The inverter needs a defined state when the ROM is not accessed. That is also a reason for having this transistor.

I haven't noticed that you have already added something to the cmos_cells project. It should be fine if we only draw the schematic for one bit there. I would just call the data input and output Dn and Qn for example. I think the schematics are better to understand with a single 8-bit memory. But of course we have to change the address inputs to row and col selectors. I can update it, yes.

Do you want to have CS and ~CS on the symbol? I think this could be confusing, because there are actual memory chips with multiple chip select inputs, that all must be enabled for the chip to be active. But it is fine if not all are enabled at the same time, the chip is just disabled then. In our case, both inputs must be switched synchronously. If they are not, then it will either only drive high or only low, depending which CS is enabled. It's an illegal state, like for the flip flops with CLK and ~CLK. Do you know what I mean?

I haven't looked into the other memories in detail. But I don't think, the WAVE RAM IO buffer is much different. I think they just attach the outside data lines a bit differently because it has separate input and output, right?