Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - Make-a-mapper competition.

Reply to topic
Author Message
  • Joined: 24 Sep 2013
  • Posts: 141
Reply with quote
Make-a-mapper competition.
Post Posted: Thu Oct 13, 2016 9:17 am
I am in the process of ordering a bunch of Sega Card clone boards and to ease the development of a mapper circuit, this boards expose all the relevant pins and lines to header blocks. Cost of making one board is the same as ten so I can give most of them away to would-be developers.

The lack of a readily available, cheap, mapper circuit seems to be an issue for many so a competition to make a mapper of any kind, SEGA compatible or not does not matter, could be a nice challenge.

I think a good criteria for entries would be:
- Being able to push past the 48K barrier (obviously)
- Simplicity (if you can make it with a few discrete ICs is better than using an FPGA/PLD)
- Ease of use (how hard is for a developer to map memory)
- How much can extend the address space (The most, the better)
- Compatibility with SEGA mapper

Competition prices? I will have to think of something yet :P

I will have segacard boards soon (a month?) and I already have some development "blank" cartridge boards that can be used to prototype. I cna give them away to would be devs if they want to. Provided is not outrageously expensive i can ship internationally for free.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3731
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Thu Oct 13, 2016 9:38 am
I can just add that a 'minimal' SEGA mapper (slot 2 bank switching - only) it's everything needed to support ROMs written with devkitSMS.
I have virtually zero knowledge in electronics, but I do think that shouldn't be too hard. After all, that should be just replacing some bits to generate a new address (input $8000-$BFFF, output from $nn000 on...)
  View user's profile Send private message Visit poster's website
  • Joined: 31 Oct 2007
  • Posts: 853
  • Location: Estonia, Rapla city
Reply with quote
Post Posted: Fri Oct 14, 2016 4:03 am
Compatibility with the Sega mapper immediately makes it require a bunch of logic chips to build :P
Codemasters mapper likeness would be much more DIY friendly on that regard.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3731
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Fri Oct 14, 2016 9:50 am
TmEE: as I said I know virtually zero about electronics, but can you try explaining me why a bunch of logic chip would be required for a minimal SEGA mapper? I can't assure you I'll understand but please shed some light towards that... :)
  View user's profile Send private message Visit poster's website
  • Joined: 24 Sep 2013
  • Posts: 141
Reply with quote
Post Posted: Fri Oct 14, 2016 10:57 am
You would need at the very least an address decoder, some signal logic and a register of some kind.

Address decoder to detect Address 0xFFFF, that alone requires a bunch of AND gates or a PLD emulating a bunch of AND gates.
Once that is out of the way you need some signal control to use the !CE/!WR signals and the Address detection from the address block, this can be done with a couple logic chips to drive the next block.
Last, you need a register to hold the mapper value. The signals from the previous block control writes to to the register and the output against the ROM IC. ROM upper address lines can be pulled down to save on an extra buffer IC.

Absolute minimum SLOT2 sega mapper could be implemented using two PLDs (ATF16V8-like ICs), a tristate parallel-in/parallel-out register, and some resistors.

I could probably throw a 128K SEGA mapper using two ATF16V8 and a single 74LS173. Adding a second 74LS173 could provide us a full 4MB SLOT2 mapper.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3731
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Fri Oct 14, 2016 11:41 am
NeonMan wrote
Address decoder to detect Address 0xFFFF, that alone requires a bunch of AND gates or a PLD emulating a bunch of AND gates.


Ok, I get that. You need to AND all the 16 bits to verify you're actually writing to the mapper, right? If that is correct, I believe every other address won't make things easier, unless it's something like it's a full range of addresses you can write to...

NeonMan wrote
I could probably throw a 128K SEGA mapper using two ATF16V8 and a single 74LS173. Adding a second 74LS173 could provide us a full 4MB SLOT2 mapper.


I checked the IC you said and if the 74LS173 is a 4-bit register then it should mean that we could have 16 x 16KB banks, which is actually 256KB, or am I missing something here?
  View user's profile Send private message Visit poster's website
  • Joined: 31 Oct 2007
  • Posts: 853
  • Location: Estonia, Rapla city
Reply with quote
Post Posted: Fri Oct 14, 2016 11:51 am
The fact that Sega mapper requires very precise addresses for the bank entries, it guarantees you have to handle all the address bits, lot of IO means lot of logic chips which makes it better to use CPLD instead, single chip, less headache.
Something that divides the 48KB into 3x 16KB with bank value set by write into corresponding 16KB area would produce a very versatile mapper that doesn't require whole lot of parts.
  View user's profile Send private message Visit poster's website
  • Joined: 24 Sep 2013
  • Posts: 141
Reply with quote
Post Posted: Fri Oct 14, 2016 12:04 pm
A single ATF16V8 is just enough to detect two 16bit address at the same time. It could output the !ADDR_FFFF and !ADDR_FFFE signals to the register latch.

Sverx: you are right, i missed a two, it is 256K, not 128K.

I think something like this could work (see attached schematic)
maybe this could work.jpg (93.24 KB)
This might work
maybe this could work.jpg

  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14652
  • Location: London
Reply with quote
Post Posted: Fri Oct 14, 2016 8:01 pm
Can't you just watch the high three address bits and the write signal, and latch the data bits when they are all 1? Add in the low two to guard against writes to addresses ending in c-e. No need to watch all 16 address lines.

I thought we had a few CPLD implementations already, just none have become commercially available yet.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3731
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Fri Oct 14, 2016 8:59 pm
Maxim: you mean that way we could trigger a slot 2 bank change by writing to any address between $E000 and $FFFF?
  View user's profile Send private message Visit poster's website
  • Joined: 24 Sep 2013
  • Posts: 141
Reply with quote
Post Posted: Fri Oct 14, 2016 9:51 pm
You can switch bank by reading the upper 2 bits of the address bus or, for slot 2, just use the !M8-B line. however to perform a page change, mapper write, you actually need to test the whole 16bit against 0xFFFF/0xFFFE since otherwise the bank registers would be mirrored al over the place.

16V8-like PLDs are cheap and easy to tinker with, (5V compatibility is a major plus) and while not the simplest mapper, I think I can have a viable SEGA mapper in a month after I get my board to tinker.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14652
  • Location: London
Reply with quote
Post Posted: Sat Oct 15, 2016 8:36 am
But mirrored registers aren't a problem. Nobody writes to e002 anyway.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3731
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Sat Oct 15, 2016 1:09 pm
... so actually we could even ignore the first two bits, as the RAM starts from $C000 and it's only 8KB and before that there's only ROM (thus no write would anyway have any effect...).
I mean we just check the third bit (from left) and the 'we want to write' pins, correct?
  View user's profile Send private message Visit poster's website
  • Joined: 24 Sep 2013
  • Posts: 141
Reply with quote
Post Posted: Sat Oct 15, 2016 4:59 pm
Any write on the mirror ram could work as a mapper write, making address detection as easy as "check the upper three address bits are set" which easy to do with discrete gates. Switching slot 2 can be done with only the !M8-B line.

Anyway. did some more testing and some more drawing... and I think I have a working circuit. I oredered to implement this mapper idea (full Slot1/2). It might be a bit overengineered but I want it to be extensible.

In total: a ROM chip, 2xATF16V8, 4x74173, 7xCaps. Same PCB for any combination of 32K/48K/256K/512K and Slot2-only/Slot 1-2
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3731
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Sun Oct 16, 2016 9:20 am
NeonMan wrote
Any write on the mirror ram could work as a mapper write, making address detection as easy as "check the upper three address bits are set"


Again here, if anyway the program won't write to ROM ($0000-$BFFF) so why can't we assume that any write to any address that has the 3rd upper bit set is a write to the mirror RAM (and thus trigger the bankswitch?). Is there something important I'm missing here?
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14652
  • Location: London
Reply with quote
Post Posted: Sun Oct 16, 2016 7:12 pm
As an aside, I've recently been messing with code that writes to ROM in order to save a few cycles in timing sensitive code...
  View user's profile Send private message Visit poster's website
  • Joined: 24 Sep 2013
  • Posts: 141
Reply with quote
Post Posted: Sun Oct 16, 2016 9:47 pm
If no ROM writes happen you can indeed simplify the mapper implementation. On my side, at the cost of added complexity I implemented the mapper to follow the SEGA mapper behaviour. It could in theory get to the 4MB limit but the largest ROM I have is 512K.

We'll see how it goes :)
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3731
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Mon Oct 17, 2016 9:33 am
You mean you're aiming to full SEGA mapper behavior or just partial (such as slot 2 only)?
  View user's profile Send private message Visit poster's website
  • Joined: 24 Sep 2013
  • Posts: 141
Reply with quote
Post Posted: Mon Oct 17, 2016 9:59 am
Slot 1/2 SEGA mapper up to 512KB. If I had an easy to solder 4MB ROM I could make it work with minor modifications.

Slot 0 seems is not being used by almost any game so I won't bother, not to mention it significantly increases complexity.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Sep 2016
  • Posts: 81
  • Location: Vienne, France
Reply with quote
Post Posted: Mon Oct 17, 2016 7:14 pm
The mapper I'm planning to build will use a MX29L3211MC 4MB flash chip, It's smd but the pitch is pretty coarse.
It's a 3.3volts chip but can be made somewhat 5volts tolerant by powering it through 2 1N4148 diodes.

There's also the MX29F1610MC which is proper 5volts but 2MB chip, you could still combine two of them.

Both can be bought from chinese suppliers on ebay or aliexpress.
  View user's profile Send private message
  • Joined: 14 Aug 2000
  • Posts: 737
  • Location: Adelaide, Australia
Reply with quote
Make-a-mapper competition.
Post Posted: Thu Oct 27, 2016 2:40 pm
NeonMan wrote
A single ATF16V8 is just enough to detect two 16bit address at the same time. It could output the !ADDR_FFFF and !ADDR_FFFE signals to the register latch.

I think something like this could work (see attached schematic)


There's no generation of the EPROM /OE in the diagram. The EPROM /OE needs to be limited to memory addresses 0x0000-0xBFFF otherwise it will cause contention with RAM. You could AND "M0-7" and "M8-B" for this. The card will not work without this.

There's no need to include /MREQ in the generation of "MAP_WRITE" because the /CE (Card Enable) is actually /MREQ ANDed with the appropriate enable bit in IO Register 0x3E.

You could also just decode A13, A14 and A15 for "MAP_WRITE" instead of all 16 address lines and still be safe.

Hope that helps.
  View user's profile Send private message
  • Joined: 14 Aug 2000
  • Posts: 737
  • Location: Adelaide, Australia
Reply with quote
Make-a-mapper competition.
Post Posted: Thu Oct 27, 2016 2:47 pm
Also, sub the 74173 with a 74374 and you have 4MB capacity.

I would also go with HC* series over LS series.
  View user's profile Send private message
  • Joined: 24 Sep 2013
  • Posts: 141
Reply with quote
Post Posted: Thu Nov 03, 2016 12:03 am
asynchronous wrote
Also, sub the 74173 with a 74374 and you have 4MB capacity.

I would also go with HC* series over LS series.


I missed that circuit existing so I am using twin 74173 instead of 74374, will probably use that one on future revisions. Also, other than power consumption, what are the benefits of using HC over LS or F?
  View user's profile Send private message Visit poster's website
  • Joined: 24 Oct 2016
  • Posts: 26
Reply with quote
Post Posted: Thu Nov 03, 2016 9:57 am
Here is an interesting link for all logic level difference :
http://www.interfacebus.com/voltage_threshold.html

Also some other points :
- As you say, power consumption. Not a big deal in master system.
- 74HC have highter propagation delay than 74LS. (74HC is slower than 74LS)
- 74HC* are more designated for new circuit design.
- 74HC and 74LS may be not compatible. 74HCT are compatible with 74LS
- 74HC was designed also to be compliant with CD4000 series

And the list grow up...

Hope that help !
  View user's profile Send private message
  • Joined: 14 Aug 2000
  • Posts: 737
  • Location: Adelaide, Australia
Reply with quote
Make-a-mapper competition.
Post Posted: Sun Nov 06, 2016 3:44 pm
For the speed and also because they're CMOS like the SMS.
  View user's profile Send private message
  • Joined: 31 Dec 2022
  • Posts: 28
Reply with quote
Post Posted: Sun Jan 01, 2023 2:17 pm
NeonMan wrote
I am in the process of ordering a bunch of Sega Card clone boards[/url] and to ease the development of a mapper circuit, this boards expose all the relevant pins and lines to header blocks. Cost of making one board is the same as ten so I can give most of them away to would-be developers.

The lack of a readily available, cheap, mapper circuit seems to be an issue for many so a competition to make a mapper of any kind, SEGA compatible or not does not matter, could be a nice challenge.

I think a good criteria for entries would be:
- Being able to push past the 48K barrier (obviously)
- Simplicity (if you can make it with a few discrete ICs is better than using an FPGA/PLD)
- Ease of use (how hard is for a developer to map memory)
- How much can extend the address space (The most, the better)
- Compatibility with SEGA mapper

Competition prices? I will have to think of something yet :P

I will have segacard boards soon (a month?) and I already have some development "blank" cartridge boards that can be used to prototype. I cna give them away to would be devs if they want to. Provided is not outrageously expensive i can ship internationally for free.






Sorry to resurrect this old discussion but I find it interesting.

This reply is related to above but it is for cartridges
not sega cards.

A modern MCU (mircocontroller) with a lot of memory (built in or externally accessed my MCU) be used to emulate a cartridge and its mapper.

For example an arduino uno has with two shift registers IC (to add 16 input lines to its 14 existing IO pins) connected to an SD memory card working
with an 16MHz crystal will work.The arduino uno would act
as a cartridge when interfaced through the cartridge slot
of the segamaster system.

"Simplicity (if you can make it with a few discrete ICs is better than using an FPGA/PLD)"
This would three (or three minimally) DIP ICs the two shift registers (very cheap ICs) and the Atmega328 IC on the arduino board (though arduino boards are so cheap may as well leave the chip on the board and put it inside the cartridge plastic shell)


"Compatibility with the Sega mapper immediately makes it require a bunch of logic chips " (from TmEE)
"Ease of use (how hard is for a developer to map memory)"

It would be quick to write high level arduino code to implement
a sega mapper (this is certainly quicker than making a sega mapper in hardware using a bunch of logic chips)
for example it the arduino would read the address values for
the slot selection register FFFF (or all high inputs for the address bits a0,a1,...,a15) and the data pins (d0,d1,...,d7) then
change the pointer in memory to the 16KB block of the The ROM image (of the game you wrote) stored on the SD card


Here is an outline of an example unfinished code for arduino


//outline i.e. incomplete arduino code -complete code would be something like
// below to implement sega mapper -code get across an idea
//of how to code it

void setup() {
// initialize the LED pin as an output:
pinMode(addressD0pin, OUTPUT);;;;only 1 data line coded here need to do 8

// initialize the pushbutton pin as an input:
pinMode(addressA15input, INPUT);only one input line coded need to do 15

}

void loop() {
// read the state of the address lines from cartridge slot:
addressState = digitalRead(addressA15input);;;;need to read 15 pins at once


;;;if all pins A0,A1,...,A15 from cart slot are read as HIGH by arduino then it means ld &FFFF is being used in z80 cartridge code
// check if FFFF is being accessed need to add similar code for a0,a1,...,a14
if (addressA15input == HIGH) {
//code to read SD card any write out byte to 8 data lines
//the SD read code will change to appropriate position depending
//on value that is intended to store in FFFF
//there will also be a memory loction in the SD card that
//stores the value of FFFF

digitalWrite(addressD0pin, HIGH);;;if the bit is HIGH use LOW otherwise

}


"Being able to push past the 48K barrier (obviously)"


An arduino SD card is 2GB easily more in size than any commercial Sega master system game.

"How much can extend the address space (The most, the better)"
It would be straightfoward to extend to use a custom mapper to
use 2GB
and 2GB is 131072*16KB blocks of memory and hence
using three custom memory locations (the arduino code is similar to the standard
memory location used at FFFF in the standard sega mapper)
holding a value between 0 to 255
is enough to identify a custom block in the 131072 16KB blocks
since 256^3 is greater than 131072.

The cost of such a cartridge would be determined mainly
by the cost of the arduino uno (or a clone or similar arduino)
and the cost of arduino card reader module (less than 1 USD
if bought many at once); using a DIP based arduino means it
can also be assembled by hand.

Most sega master system games do not use extra RAM inside
a cartridge so the arduino code can be simplified by not
implementing emulation for RAM on a cartridge using
flash memory-though the code may be based on the code
that implement the storage of the value in the register
FFFF in flash memory.
  View user's profile Send private message
  • Joined: 25 Feb 2006
  • Posts: 862
  • Location: Belo Horizonte, MG, Brazil
Reply with quote
Post Posted: Sun Jan 01, 2023 4:07 pm
In theory, it would be possible to use a MCU to emulate a mapper, but the question would be if the AVR used by Arduino would be fast enough for that. The Harmony Cart for Atari 2600, for example, uses a 87MHz ARM CPU inside the cartridge in order to emulate the mappers.

Also, SD cards are serial block devices, and, as a result, can't be directly used for ROM emulation.It would be necessary to load them into RAM or Flash EEPROM in order to be realistically useable as ROM. On the other hand, if you're willing to break compatibility with existing cartridges, it would be possible to write games specifically made to make use of the SD card as a block device; it still would be nice to have some extra RAM in that case.
  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 592
  • Location: London, UK
Reply with quote
Post Posted: Sun Jan 01, 2023 5:58 pm
The serial EEPROM I'm currently using (W25Q80DVSNIG) I reckoned could maybe talk fast enough at dual or quad data rates to emulate a parallel ROM although I haven't actually tried it and this was just some idle calculations in my head while flicking through the datasheet so might be flawed. Also it's 3.6v max of course.

From personal experience, using SoC systems to emulate logic has always proven to be more of a pain in the ass than I anticipated, I reckon discrete or programmable logic is ultimately a better bet. It also depends on your use case: if you want to completely replicate a real Sega mapper it's quite involved, but implementing an arbitrary mapper just for your own game means you can design from scratch and make it simpler.
  View user's profile Send private message Visit poster's website
  • Joined: 31 Dec 2022
  • Posts: 28
Reply with quote
Post Posted: Mon Jan 02, 2023 1:18 am
"but the question would be if the AVR used by Arduino would be fast enough for that. "

There is projects around the internet that use an Arduino Uno to emulate a EPROM for a z80 (not used in a sega master system project) so that is evidence that show it would work-I personally would not be surprised if it did work, after all, an AVR did come out at least 25 years after the z80 so it's light years ahead technologically. Even if an Arduino Uno with ATmega328 did not work you could use a ESP8266 (which can be programmed with the arduino IDE) that can be bought for about a dollar in bulk and which runs at 150MHz and has 32MB RAM and 512KB flash.
  View user's profile Send private message
  • Joined: 14 Aug 2000
  • Posts: 737
  • Location: Adelaide, Australia
Reply with quote
Make-a-mapper competition.
Post Posted: Mon Jan 02, 2023 2:57 am
The fastest memory cycle for the Z80 is an opcode fetch, where the /MREQ and /RD strobes go down halfway through T1 and data should be stable on the data bus halfway through T2. That gives a little over one T-state of time to do everything you want to do. Let’s call it at 300nS.

At 16MHz, 300nS is only 5 instructions. 10 instructions for 33MHz. 50 instructions for 150MHz. Seems like using an AVR would be a challenge, but using the ESP it could be achievable.
  View user's profile Send private message
  • Joined: 06 Mar 2022
  • Posts: 592
  • Location: London, UK
Reply with quote
Post Posted: Mon Jan 02, 2023 8:57 am
The other thing to be aware of is the GPIO speed.
When I was emulating the SMS VDP using a Raspberry Pi Zero, the GPIO could only really operate at around 1MHz, so I had to connect a pin to the ~WAIT line of the Z80 to throttle the requests.

On that note, emulating on a single core at the ~700Mhz the pi zero defaults to was just slower than real-time, and I think I optimised my code pretty well. There was no OS, it was completely bare bones. Tuning up to ~900Mhz I reckon just about ran real-time but I hadn't yet implemented sound. You need around 25Mhz internally to run the VDP with digital output. At least with the VDP you can externally buffer because the VRAM pointer autoincrements, and you also have the access slots which naturally throttle, but you can't do that with random access of a ROM, so you have to fall back to @async's analysis.
Anyway, just an illustration maybe that "light years ahead" technology doesn't necessarily apply when you are trying to get an mpu, which operates serially, to do largely parallel work where the timings are defined at the order of gate delays...
  View user's profile Send private message Visit poster's website
  • Joined: 25 Feb 2006
  • Posts: 862
  • Location: Belo Horizonte, MG, Brazil
Reply with quote
Post Posted: Mon Jan 02, 2023 10:33 am
On the other hand, if you don't intend to keep compatibility with existing games, you could add lots of RAM and a SD card connector to the cartridge; it would be possible to have huge games that way, but it would be necessary to stream the required data from the SD card to RAM, much like a CD game. You could also add a MCU as a coprocessor for whatever you would intend to do.
  View user's profile Send private message Visit poster's website
  • Joined: 24 Mar 2021
  • Posts: 116
Reply with quote
Post Posted: Mon Jan 02, 2023 6:46 pm
AVR is not fast enough.
For whatever reason, to emulate an asynchronous ROM you really do need around 60-100x the CPU speed on a microcontroller that cannot stall.

There's been a bunch of "ROMulators" for various systems - beyond the well-known Harmony Cart for the 2600, I've seen ones for the SNES ("SNES DRONE"), N64 ("PicoCart64"), and someone's told me some things in private about using a Pico on the SMS although they haven't said anything publicly.

The full Pis are horrible about stalling. Their DRAM controller randomly steals cycles that makes submicrosecond response times basically impossible.
  View user's profile Send private message
  • Joined: 09 Aug 2021
  • Posts: 91
Reply with quote
Post Posted: Tue Jan 03, 2023 8:22 pm
I have another idea: why not make a wires-only adapter for the game boy flash carts? Cheap reflashable 2 or even 4 mb bootleg pokemons with battery backed-up sram cost 3-5$ on aliexpress.
  View user's profile Send private message
  • Joined: 24 Mar 2023
  • Posts: 15
Reply with quote
Post Posted: Sat Mar 25, 2023 3:30 pm
RE GPIO speed concerns:

What about the RP2040s PIO? I'm still learning how it works, but you have 30 GPIO pins to program which would be more than enough.

If you have all the address and data pins being listened to by the RP2040, then FIFO the data to and from the main ARM core for decoding, I'm pretty sure you could make it happen fast enough for the Z80 to be happy.

You can also run the clock as high as 133Mhz...almost seems like overkill!
  View user's profile Send private message
  • Joined: 24 Mar 2021
  • Posts: 116
Reply with quote
Post Posted: Sat Mar 25, 2023 6:00 pm
PIO code can only hold two states internally (called "X" and "Y"). So a very limited mapper using just the PIO could consist of code that was something like

"wait for gpioA to go high
load scratch X
store to gpioB-C
wait for gpioA to go low
load scratch Y
store to gpioB-C"

There's plenty of places this might be sufficient, but people expecting the traditional SMS mapper might find it cramped.

On the other hand, the RP2040 actually has fast enough GPIO and fast enough ROM that it can emulate the whole cartridge without using it with an external parallel ROM. I've been talking to someone who's been working on this.
  View user's profile Send private message
  • Joined: 24 Mar 2023
  • Posts: 15
Reply with quote
Post Posted: Sat Mar 25, 2023 6:19 pm
That's why you'd FIFO the data to the ARM core for processing right? Not that I know enough about the Pico's PIO to hold an intelligent conversation about it :V
  View user's profile Send private message
  • Joined: 24 Mar 2021
  • Posts: 116
Reply with quote
Post Posted: Sun Mar 26, 2023 4:45 pm
The problem with FIFOing data from the THUMB cores is that you have to already know the values that you will have needed... you can't react to what the Z80 is doing.
  View user's profile Send private message
  • Joined: 03 Mar 2022
  • Posts: 55
Reply with quote
Post Posted: Wed Mar 29, 2023 7:17 am
Recently I was evaluating the use of RP2040 PIO for a simple mapper (not for the SMS, but for the Megadrive). I think it might be doable using two different PIO state machines (one to monitor address and control bus lines and actually switch the bank according to them and an internal X/Y register value and other to interface the console parallel bus) but with a few caveats:

* The mapper should be write-only (i.e. no memory mapped registers you can read, since involving the CPU and FIFOs will not be fast enough for a read cycle without wait states).
* Bankswitching will most likely not be able to be performed in a single cycle, so software should take this into account (i.e. when software wants to bankswitch, it would write to the bank control reg, then the RP2040 will take some time to sync with the other state machine for the bankswitching to actually take effect. If the SMS expect the bankswitch to be stable on the next CPU instructions just before the one doing the switch... you might have problems).

Unfortunately when PIO PUSH/PULL operations are involved, latency increases a lot, making things difficult. Another thing you have also to take into account is that MCUs have input synchronizers (to avoid metastability). Typically they use 2 flip-flops adding two extra clock delays on inputs. Not much when your clock is 133 MHz, but well, you have to take it into account. IIRC RP2040 allows disabling the synchronizers, but if you do, you have to be careful to respect setup/hold times or shit will happen. And this can be tricky because usually these MCUs use a clock independent of the one in the console.

As PIOs seemed not that good whey I evaluated them for this task, I was also considering not using them, and just using one of the two cores to continuously poll the bus. Not an elegant solution for sure, but this should work fast enough, and you have another CPU core to do any other task you want...
  View user's profile Send private message
  • Joined: 03 Mar 2022
  • Posts: 55
Reply with quote
Post Posted: Mon Apr 24, 2023 5:28 pm
It's not for the SMS, but it looks like someone used an RP2040 to emulate ROMs for the Amstrad CPC (another machine with a Z80 running at 4 MHz). It used the strategy I suggested: dedicating a CPU core to ROM emulation. And it looks like the RP2040 had to be overclocked to 225 MHz...

https://www.hackster.io/news/matt-callow-turns-a-raspberry-pi-pico-into-a-low-co...
  View user's profile Send private message
  • Joined: 10 Dec 2009
  • Posts: 103
Reply with quote
Post Posted: Fri May 05, 2023 9:30 am
doragasu wrote
It's not for the SMS, but it looks like someone used an RP2040 to emulate ROMs for the Amstrad CPC (another machine with a Z80 running at 4 MHz). It used the strategy I suggested: dedicating a CPU core to ROM emulation. And it looks like the RP2040 had to be overclocked to 225 MHz...

https://www.hackster.io/news/matt-callow-turns-a-raspberry-pi-pico-into-a-low-co...


It requires level shifters. Am I right?
  View user's profile Send private message Visit poster's website
  • Joined: 24 Mar 2021
  • Posts: 116
Reply with quote
Post Posted: Fri May 05, 2023 6:29 pm
siriokds wrote
It requires level shifters. Am I right?


Offically, yes.

In practice, the digital-only pins on the RP2040 use a different overvoltage protection system that can apparently be safely exposed to 4.5V, so if you are interfacing with something that's 5V and not CMOS you may not need translation.

Unfortunately, I don't know which systems are in that group.
  View user's profile Send private message
Reply to topic



Back to the top of this page

Back to SMS Power!