Question about documentation and BUS

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

Moderator: Moderators

Post Reply
odelot
Posts: 14
Joined: Mon Aug 27, 2018 7:33 am

Question about documentation and BUS

Post by odelot »

Hi folks,

The question is: does /ROMSEL (on the cartridge slot) is LOW (active) even if the CPU is not reading the ROM? ($8000–$FFFF - this is, M2 LOW and A15 HIGH)

Just to explain from where my question come from:

In this doc page https://www.nesdev.org/wiki/Cartridge_connector it states that:
/ROMSEL: This pin outputs the logical NAND of M2 and CPU A15. It is low when the CPU reads or writes to $8000–$FFFF and when the address is stable, allowing to enable ROM chips directly. Advanced mappers use more logic between this pin and the actual PRG /CE (to avoid bus conflicts, for example). Using this signal is the only way to determine the state of A15, so it's needed for any mappers doing any address decoding.
Does it need to be LOW when A15 is HIGH (address $8000–$FFFF) and M2 is LOW?

Also, in the docs, it is stated in the cart schematic that "/ROMSEL (/A15 + /M2)" = NOT(A15) OR NOT (M2) = NAND (A15, M2)

Just to make clear, ROMSEL = NAND(A15,M2) and in the cartidgre slot we have /ROMSEL, that is, NOT (ROMSEL), is that right? I was a little confused in this part.

Thanks in advance guys
lidnariq
Posts: 11497
Joined: Sun Apr 13, 2008 11:12 am

Re: Question about documentation and BUS

Post by lidnariq »

No-where is ROMSEL-without-the-leading / used, and that's deliberate. There's only the one signal.

It's low when, and only when, the CPU is accessing (M2 is high) the region from $8000 and up (where A15 is high). At all other times /ROMSEL is high.
odelot
Posts: 14
Joined: Mon Aug 27, 2018 7:33 am

Re: Question about documentation and BUS

Post by odelot »

lidnariq wrote: Mon Jun 03, 2024 5:46 am No-where is ROMSEL-without-the-leading / used, and that's deliberate. There's only the one signal.

It's low when, and only when, the CPU is accessing (M2 is high) the region from $8000 and up (where A15 is high). At all other times /ROMSEL is high.
thanks! I wrongly assumed /ROMSEL would be low when M2 is low, telling that is stable to do things.

From your answer I undertood that M2 is low because A0-A14 is stable and D0-D7 is stable, but ROMSEL just need to be enabled when M2 is high (and CPU is using the BUS).

I would like to infer A15 during M2 is LOW, but it seems will not be possible.

My goal is capture WRAM using the cartridge slot
lidnariq
Posts: 11497
Joined: Sun Apr 13, 2008 11:12 am

Re: Question about documentation and BUS

Post by lidnariq »

6502-based machines have a positive-sense enable that means the address bus is valid (φ2 on other machines, M2 on the NES).

You don't get to know the contents of A15 while M2 is low, but you also mostly don't care (because M2 low means the address bus is not valid).

Note that the data bus is not stable while M2/φ2 is high. It is only guaranteed/required to be correct on the falling edge of M2/φ2
odelot
Posts: 14
Joined: Mon Aug 27, 2018 7:33 am

Re: Question about documentation and BUS

Post by odelot »

My initial idea was to intercept the falling edge of M2, get A0-A15, D0-D7, WR/RD. If A11-A15 are zero, CPU is intend to write on WRAM and I can capture it.

So I think A15 is kind of important to me, to understand if address is really between 0x0000 to $1FFF.

I will try to capture the raising of M2 to get A15 and be sure the data is really for WRAM.

Does it make sense?
Last edited by odelot on Mon Jun 03, 2024 11:52 am, edited 1 time in total.
lidnariq
Posts: 11497
Joined: Sun Apr 13, 2008 11:12 am

Re: Question about documentation and BUS

Post by lidnariq »

In OEM NESes, the 74'139 that generates /ROMSEL is delayed by about 20ns. This means that on the falling edge of M2, /ROMSEL is still valid and is /A15.
odelot
Posts: 14
Joined: Mon Aug 27, 2018 7:33 am

Re: Question about documentation and BUS

Post by odelot »

lidnariq wrote: Mon Jun 03, 2024 10:00 am In OEM NESes, the 74'139 that generates /ROMSEL is delayed by about 20ns. This means that on the falling edge of M2, /ROMSEL is still valid and is /A15.
Thank you for this valuable info.

I really need some logic analyser with more than 8 channels to understand and debug the bus better.
odelot
Posts: 14
Joined: Mon Aug 27, 2018 7:33 am

Re: Question about documentation and BUS

Post by odelot »

lidnariq wrote: Mon Jun 03, 2024 10:00 am In OEM NESes, the 74'139 that generates /ROMSEL is delayed by about 20ns. This means that on the falling edge of M2, /ROMSEL is still valid and is /A15.
I was debugging with a logic analyser and it seems that /ROMSEL keeps high during the falling of M2 when WR/RD is LOW, even if it will stay high during the raising and during the M2 HIGH.

It seems that if the BUS will be used by memory, CPU don't care about /ROMSEL and it is always HIGH.

I know my approach is not ideal, I am not using FPGA and I am relying on CPU speed to try to syncronize with M2 clock.

Now I am using a combination of /ROMSEL and WR/RD to get the memory address CPU is writing, both on rising and falling and ignoring /ROMSEL as A15 to compose de address.

So far I could get some memory writes. I am testing with rad racer and I could get when I pause the game (the CPU writes on memory OxE4) but it misses sometimes.

My next step is using MCP23S17 to speed up things on reading the BUS and continue to invest on speed over accuraccy. Otherwise I will jump to FPGA and do it all in parallel to act exactly during the falling.

PS: another question: Is it common for games to use mirrored memory addresses?
lidnariq
Posts: 11497
Joined: Sun Apr 13, 2008 11:12 am

Re: Question about documentation and BUS

Post by lidnariq »

odelot wrote: Sun Jun 09, 2024 3:11 am I was debugging with a logic analyser and it seems that /ROMSEL keeps high during the falling of M2 when WR/RD is LOW, even if it will stay high during the raising and during the M2 HIGH.

It seems that if the BUS will be used by memory, CPU don't care about /ROMSEL and it is always HIGH.
On all consoles, it is required that /ROMSEL is low if A15 is high and M2 is high.

The delay is only present on the OEM NES, due to the 74'139. Later NES-on-a-chips don't have much extra delay. (They must have some, for compatibility with commercial games)
My next step is using MCP23S17 to speed up things on reading the BUS and continue to invest on speed over accuraccy. Otherwise I will jump to FPGA and do it all in parallel to act exactly during the falling.
I/O expanders are rarely fast enough for this. Good luck.
PS: another question: Is it common for games to use mirrored memory addresses?
Licensed games mostly use one mirror. Different games choose different ones. (Some MMC1 games write to $8000, some to $9FFF).

Unlicensed games often fill the ignored bits with random noise to obfuscate what's going on.
odelot
Posts: 14
Joined: Mon Aug 27, 2018 7:33 am

Re: Question about documentation and BUS

Post by odelot »

lidnariq wrote: Sun Jun 09, 2024 4:40 am
odelot wrote: Sun Jun 09, 2024 3:11 am I was debugging with a logic analyser and it seems that /ROMSEL keeps high during the falling of M2 when WR/RD is LOW, even if it will stay high during the raising and during the M2 HIGH.

It seems that if the BUS will be used by memory, CPU don't care about /ROMSEL and it is always HIGH.
On all consoles, it is required that /ROMSEL is low if A15 is high and M2 is high.

The delay is only present on the OEM NES, due to the 74'139. Later NES-on-a-chips don't have much extra delay. (They must have some, for compatibility with commercial games)
My next step is using MCP23S17 to speed up things on reading the BUS and continue to invest on speed over accuraccy. Otherwise I will jump to FPGA and do it all in parallel to act exactly during the falling.
I/O expanders are rarely fast enough for this. Good luck.
PS: another question: Is it common for games to use mirrored memory addresses?
Licensed games mostly use one mirror. Different games choose different ones. (Some MMC1 games write to $8000, some to $9FFF).

Unlicensed games often fill the ignored bits with random noise to obfuscate what's going on.
Thank you for all the useful information and insights.

I will keep you updated with my progress.

Had to halt everything this week because I am organizing a retro event to play with my friends.
odelot
Posts: 14
Joined: Mon Aug 27, 2018 7:33 am

Re: Question about documentation and BUS

Post by odelot »

About speed over accuracy, does anyone know how people are using Raspberry Pico to handle the BUS in these new projects? It looks like they are using PICO to create a N64 Everdrive.

It is difficult to rely on digital interrupts and readouts because they are delayed and slow. An example: even an ESP32 with 240 MHz CPU, you get at most 400k interrupts per second. You can optimize the reading via registers and try to detect clock changes by brute force, but you will not be synchronized with the NES clock or with the exact moment the clock drops.

But I assume people are using something similar on the N64 with PICO (with its ~120MHz). I haven't looked into the architecture of the N64 or how they do it yet, but probably it is a good study.

If someone more experienced could clarify the use of PICO for the N64 everdrive and the differences between N64, NES and SNES (would it be possible to create simple everdrives with PICO for NES and SNES?) it could be an interesting topic to discuss ^.^
calima
Posts: 1756
Joined: Tue Oct 06, 2015 10:16 am

Re: Question about documentation and BUS

Post by calima »

The Pico has PIO programmable engines, which greatly increase its response rate. It doesn't act via irqs or manual polling.
odelot
Posts: 14
Joined: Mon Aug 27, 2018 7:33 am

Re: Question about documentation and BUS

Post by odelot »

calima wrote: Tue Jun 11, 2024 7:50 am The Pico has PIO programmable engines, which greatly increase its response rate. It doesn't act via irqs or manual polling.
Thank you! I will give it a try before invest more time on manual polling with SPI.
lidnariq
Posts: 11497
Joined: Sun Apr 13, 2008 11:12 am

Re: Question about documentation and BUS

Post by lidnariq »

The N64 cartridge bus is for high-latency in-order bulk transfers. This means that handling it is very easy: you have a huge amount of time after getting the address to fetch the first word (around 1000ns), and then you know all subsequent data will be that immediately following.

This is not true on almost all other cartridge-based systems, where they are not high-latency and they are not in-order. For the NES CPU you have about 350ns, ish, and it often has nothing to do with the previous fetch.
Post Reply