Forums

Hello everybody !

I'm new on this forum, and I'm French with bad English so I apologise in advance for my bad one.

Electronics is my great passion, and I grow up with Master System. I recently got two SMS 2 (one US and one EU), and I want to combine my SMS passion with my Electronic passion.

My goal is to create some stuff for the SMS, like rewritable cartridge, saga cartridge, cheat cartridge....

I Began with a simple Cartridge reader. Next I want create my own Rewritable Cartridge with SRAM and custom mapper (if I doesn't found any mapper)

I really thanks this community, where all docs, pin-out, and architecture explanation have help me to build this modest circuit.

In order to give you in return of your excellent work on SMSPower.org, I give you my work soon. (Schematic, AVR code, and Java -sry- code)). My SMS reader work with shift register (3 Serial to Parallel and 1 Parallel to Serial) and a so called Arduino Uno.

I have obviously tons of questions concerning the hardware and software. I apologise in advance if some answer have already given. I spent lot of time (and headache) reading and surfing on the forum/site.

1) I read all and it opposite about cartridge. Some docs tell that they only exist 128K and 256K (AFAIK 32K exist obviously) and other tell that only 32K, 128K and 512K exist. Who to trust ?

2) In the same way, 32K is without mapper (0x8000 bytes length). But, Without mapper, we can access 0xC000 bytes of data, in other world 48K bytes of data. Do they exist 48K ROM ?

3) I try my SMS Reader on a simple 32Kb rom, "Super Tetris". The ROM chip have 16 bus address. I realy dont understand why :
- To access 32K bytes, only 15 bus address is needed.
- This ROM doesn't have Mapper, so the 0xFFFF doesn't need to be accessed.
Why the ROM have this 16th bus address ?

4) I have assumed on my SMSReader that /RD and /RW pin are both LOW active (RD to 0 mean we read, or RW to 0 mean we write on ROM). I found some docs in contradiction with that. Who to trust ?

5) I don't understand the behaviour of /Mreq and /IOReq cartridge pin. Can you explain this to me ?

6) In the same way, on mapper, I don't understand the "ROM write" enable bit on register 0xFFFC. The write can only affect the cartridge RAM, no ?

7) If I understand correctly, the cartridge can set /BusReq to 0, and when the CPU answer with /BusAck setted to 0, the cartridge can for example write on address bus to read/write on system RAM ?
(I ask this in order to make a cheat card)

8) I don't found any list of cartridge know to have separate mapper chip. Were to find it ?

Thanks in advance !

Hi, and welcome.

1. Cartridges exist at 32, 128, 256, 512 and 1024KB, but other sizes are possible. I think there might be a 64KB Game Gear game.

2. Not as far as I know. I think the manufacturing costs for 48KB may exceed that of 128KB, as it would require more chips.

3. The chip may be larger than 32KB internally? Or it's to make sure not to respond with the data from 0000 when 8000 is read.

4. The cartridge may not care about /WR. Almost everything is active low logic, but some docs may miss that important fact.

5. The Z80 (and many modern CPUs) has two buses it can address, memory and I/O. The latter is intended for peripherals, is used for everything except ROM, paging and RAM on the SMS, and is generally considered to only have 8 address lines (the upper 8 do carry some information but you need not care). It signals which one it is reading or writing using those lines, which then appear on the cartridge port. This allows the cartridge to correctly determine if it is ROM being read.

6. This is a testing feature for development boards and no known software actually uses it.

7. I guess so? It will mess with cartridge timing though...

8. It's not super well documented, the SMS Reader docs are the best we have. These days, "repro" makers are keeping their information close to avoid competion on the cartridges :) and I think there are not many games that are guaranteed to have a mapper inside. A homebrew cartridge would be much better.

Thanks !

1) Whoa ! 1024K ? very large ! (lol I'm stupefied by this big size, as I'm using 128Gb USB key.)

2) Yeah, manufacturing cost can explain this. 32K is a full address range ROM (15 addr bus) but 48K is a bastard adress range (16 addr bus stopping at 0xBFFF).
The only way to cover 48K band is to use a 64K rom (48K rom doesn't exist), wich 16K unused. And 16K unused is a waste of money. Why don't I conclude this by myself ?

3) The chip I use to test my reader is, by test, effectively 32K large, not more. When accessing after 0x7FFF, the data is unclear and realy random, I can have different data at same location when reading multiple time.
Its very likely the chip go on High Impedance (Hi-Z) mode on data line when accessing after 0x7FFF.
You may be right, the 16th line address is here to prevent sending data, bus contention or mirroring after 0x7FFF

4) Thanks for confirm that fact. I assumed that 90% SMS logic work at low logic. Like 90% of electronic logic. The ROM I read have a /RW pin. on his chip. I assume that's for put data line in High Impedance if SMS want access FCR.

5) Strangely, the ROM I test have /Mreq and /IOReq left disconnected.

6) Hooo okay ! for debugging purpose ! That make sense !

7) Yes, timming may be affected, of course. But the idea is here.

8) Mkay ! I will work with logic IC, building my own mapper will be a great challenge !

in theory, i imagine that the sms default pager would support 4mbyte roms (just like used from ascii16 pager from msx), but i guess no games larger than 1mbyte were manufactured in the 80’s and 90’s (and wouldn’t have support from most emulators because of that, i guess) - and some korean/taiwanese bootleg roms (conversions from konami’s msx games) would access 2mbyte roms (uses 8kbyte pages instead of 16kbyte)

i guess also that, if 2 bytes were used for paging instead of 1, we would be able to access 1gbyte cartridge instead of 4mbyte only - the problem is how could we make this, from the homebrew scene, as a convention that would be supported on emulators, sd-cartridges, fpga clones, etc.

Everdrive has a 1MB limit so that's a de facto limit for homebrew. Most emulators support 4MB. Any new mapper would take time to get support.

nitrofurano wrote

i guess also that, if 2 bytes were used for paging instead of 1, we would be able to access 1gbyte cartridge instead of 4mbyte only - the problem is how could we make this, from the homebrew scene, as a convention that would be supported on emulators, sd-cartridges, fpga clones, etc.

Going by what I've observed in the past, the kick in the pants that usually does it is a developer going ahead and making software for such a theoretical format. Assuming some sort of implementation of it exists at a hardware or emulator level, of course.

Suddenly the interest in actually implementing support for the hardware that software uses erupts.

Of course, this isn't an excuse to rush out ahead with poorly thought out hardware.

I believe Emulicious supports the db-electronics homebrew mapper which doesn't exist yet... I think what is needed is an actual hardware release of a decent game.

I really don't understand the need of have a 1Gbyte storage cartridge.... If we want turn the SMS into a Computer I understand.

Let's go back to the point :

• Yesterday I finally test the /BUSREQ function. That work well ! So I stole all buses of the Z80 then I read by hard-wiring selecting 0xDC port the button states of my controller by conecting LEDs on DATA BUS.
To select by hardware, I processed in this order (That's important, to avoid bus contention and short circuit) :
- Connect a LED on /BUSACK (with resistor obviously, in sinking current, minus of led connected to the /BUSACK)
- Connect 8 LEDs on the DATA BUS (with resistor obviously, in sinking current too)
- Connect /BUSRECK to ground
- Wait for the LED on BUSACK to bright (Approx 0.01 ms :) )
- Connect A0 to ground
- Connect A6 and A7 to VCC +5V
- Connect /IOreq and /RD to ground
- Enjoy LED brighting by pressing button on controller !

Here is my observation :
- BUSREQ can really stole safely all Z80 buses in order to use all SMS hardware, with custom hardware.
- Obviously the Z80 "freeze", not pause ! he literally freeze at current PC.
- DRAM was good enough to maintain data at last 5 big second safely. After too much time stilling buses, DRAM become unclear and the current game can become buggy, or restart at launching.

I test this behaviour with the on-board game Alex Kid. So I couldn't test this point :

The "Super Tenis" ROM I use to test my SMSReader is connected as follow : A0-A15, D0-D7, /RW pin, /CE pin. I don't understand why the /Mreq pin is not connected :
When the CPU access to IOPort, HOW the rom know that it must free data bus ?

The ONLY way to do that is that the IOPORT Chip who control /CEs lines free data buses by holding all /CEs up.

Anyone can confirm that ?

leviatan wrote

I really don't understand the need of have a 1Gbyte storage cartridge.... If we want turn the SMS into a Computer I understand.

1: “because we can”! :D
2: even considering that a game wouldn’t take closer to 1gbyte (even a Myst remake! :D ), being able to produce rom files larger than 4mbytes, and not having silly constraints about rom size, seems interesting and provide some room for our homebrew creativity

One thing I've considered is that with the right code, you can access the SD file system on the Everdrive, giving a lot of space at probably low speeds. Emulating that would be a pain, though.

Maxim wrote

I believe Emulicious supports the db-electronics homebrew mapper which doesn't exist yet... I think what is needed is an actual hardware release of a decent game.

I still dream of an official SMS Power! collection cartridge with a few among the best homebrew we made here over the years, with a graphical boot menu for selecting the desired game. If we only could have the plastic shells we never found a way to have, we could surely convince db-electronics to add the needed bank-offsetting mapper feature.
Still, I didn't give up on this.

cases are the easy (expensive?) part if you have a 3D printer. A catridge with a mapper is the hard part.

I'm working on it ;)

well, actually we've got a suitable and feature rich cart since more than a year (see this video) but we still have no affordable way to shells :|

Sorry but nobody can tell me if im right ?

"The ONLY way to do that is that the IOPORT Chip who control /CEs lines free data buses by holding all /CEs up."

Therefore, I see an immediate possibility to make a custom cartrige with 64, 128 Gbytes.

By using SD card.

We dont touch at the mapper at all. Ok so :
- One classic mapper (covering all game possibility)
- One 4Mib SRAM connected to the mapper,
- One 32k SRAM connected to the mapper,
- One MCU (Micro Controler Unit) connected to the Cartridge buses
- One SD Card slot on the cardridge conected to the MCU.

The Idea :
In the SD, we have :
- A custom BOOT ROM who list all ROMs wanted,
- All wanted ROMs displayed at startup

The custom BOOT ROM will write to RAM (a dedicated address, no mather if SMS DRAM or Cartridge SRAM) the choice of the user.
We call this address ADDR_USER_CHOICE

Functioning :
- MCU : At startup, MCU immediatly hold buses with /BUSREQ.
- MCU : load custom BOOT ROM in 4Mib SRAM.
- MCU : release buses
- SMS : take on and execute custom ROM.
- SMS : Custom BOOT ROM display list of all game wanted.
- MCU : Periodicaly, MCU hold buses to read ADDR_USER_CHOICE see if a choice was written on (for exemple, 0x00 no choice given, other number is the number of the game)
- SMS : The user select a game, writted on ADDR_USER_CHOICE by Custom BOOT ROM
- MCU : After the successful read of ADDR_USER_CHOICE, MCU keep buses holding in order to load wanted ROM into 4Mib SRAM.
- MCU : Reset PC of SMS to startup,
- SMS : take on and execute wanted ROM.

That's my final goal.

Hello all !

Somes news :

I successfully used a SRAM as ROM cartridge for my master system. I don't have make a mapper, therefore and because I am limited to 32K, I loaded my previous awesome dumped Super Tennis game.
That's work almost perfectly, but I need to disengage my custom cartridge to write on it. I must add Tri-State buffer to prevent SMS being in conflict when witting.

I assumed that the original Super Tennis roms use the /M0-8 to set DATA pin in High-Z when accessing upper than 0x8000. I do the same with my SRAM chip by ORing the /RD, /M0-8 and /Mreq signals.
The SRAM I used : AS6C4008.

I ll test all these behaviours :
- When CPU access IOPort, CE of the cartridge become Hight ?
- When CPU access RAM (Upper than 0xC000), CE of the cartridge become Hight ?

Do you know how to reset the CPU ? Must I do this in ASM (to reset the Program Counter and the IOChip) or there is an hardware solution ?
The RESET pin of the cartridge port seems to be an OUTPUT, so we can't use it.

leviatan wrote

Hello all !

Somes news :

I successfully used a SRAM as ROM cartridge for my master system. I don't have make a mapper, therefore and because I am limited to 32K, I loaded my previous awesome dumped Super Tennis game.
That's work almost perfectly, but I need to disengage my custom cartridge to write on it. I must add Tri-State buffer to prevent SMS being in conflict when witting.

I assumed that the original Super Tennis roms use the /M0-8 to set DATA pin in High-Z when accessing upper than 0x8000. I do the same with my SRAM chip by ORing the /RD, /M0-8 and /Mreq signals.
The SRAM I used : AS6C4008.

I ll test all these behaviours :
- When CPU access IOPort, CE of the cartridge become Hight ?
- When CPU access RAM (Upper than 0xC000), CE of the cartridge become Hight ?

Do you know how to reset the CPU ? Must I do this in ASM (to reset the Program Counter and the IOChip) or there is an hardware solution ?
The RESET pin of the cartridge port seems to be an OUTPUT, so we can't use it.

When reading or writing to an IO address, the Z80 CPU asserts (i.e. pulls low) the /IORQ line. When reading or writing a memory address, the Z80 CPU asserts (i.e. pulls low) the /MREQ line. So the 2 address spaces can co-exist without a problem.

The /CE line on cart slot is the CPU /MREQ line AND-ed with the corresponding bit in the register mapped to IO port 0x3E. So /CE stays high when the CPU reads or writes to an IO address.

The /CE lines do not take into account the CPU address. That means for a read or write to a memory address in the RAM address space (0xC000 to 0XDFFF) the /CE line on the Cart slot will go low.

On early SMS the reset circuit was just a passive RC circuit. On later SMS and the SMS2 the reset circuit is buffered and driven by an output on IC4 which is what you're seeing. I haven't tested what it takes to pull the reset output to a logic low.

Hope that helps.

Thanks for answer. Yes it really help me !

Maxim already explain to me the purpose of /Mreq and /Ioreq. You completed this explanation well !
My assumption was right. So I can use only /CE and don't care about /Mreq. This will save one logic gate.

for the RAM address range, this is why the 15th address is used in the cartridge rom (in fact this is the /M0-8 pin). This is an "output enable" purpose to prevent bus contention.
Same things for the /RD pin.
I observe this behaviour when dumping my 32K rom. I didn't found ANY datasheet for the ROM used in this Super Tennis game, its not a Sega chip, I'm sure that this chip is in fact a simple generic 32K rom linked to complies with SMS.

For the reset circuit... Mhhh I can't use that way. On RC circuit it's not a problem to go low, but on IC output its an other thing.
With open-collector technologies it's fairly simple to combine two output, but I read that SMS is build with CMOS and its a really bad design to force an output to go low by that way. I don't want do a trashy patch, I must find a better way.
Maybe by writing 0 to the bit 4 of $DD Port ? I think it can't be done, as the $DD port seems to be read only.

Hi,

I added Tri-State Bidirectional Buffer in data and addresses buses. That's work well, priority is correctly given to the MCU (Micro Controller Unit) when writing ROMs.
So we can let the SMS running when writing on it. SMS become buggy as it can't read data, but there is no buses contention at all. A simple restart at end of writing and we can play game.
My bidirectional buffers let the MCU access to all Z80 buses. I can hold buses, read or write on IOPorts or Memories.

Im working on a very simple register with logic IC, holding only the FCR 0xFFFF. I read that almost all game only use that register. Can you confirm that ?

The last thing where im stuck is how to reset the SMS. I want let the possibility to write a ROM then restart the SMS without turning it OFF then ON.

Author	Message
leviatan Joined: 24 Oct 2016 Posts: 26	Noob on board Posted: Tue Oct 25, 2016 8:30 am
leviatan Joined: 24 Oct 2016 Posts: 26	Hello everybody ! I'm new on this forum, and I'm French with bad English so I apologise in advance for my bad one. Electronics is my great passion, and I grow up with Master System. I recently got two SMS 2 (one US and one EU), and I want to combine my SMS passion with my Electronic passion. My goal is to create some stuff for the SMS, like rewritable cartridge, saga cartridge, cheat cartridge.... I Began with a simple Cartridge reader. Next I want create my own Rewritable Cartridge with SRAM and custom mapper (if I doesn't found any mapper) I really thanks this community, where all docs, pin-out, and architecture explanation have help me to build this modest circuit. In order to give you in return of your excellent work on SMSPower.org, I give you my work soon. (Schematic, AVR code, and Java -sry- code)). My SMS reader work with shift register (3 Serial to Parallel and 1 Parallel to Serial) and a so called Arduino Uno. I have obviously tons of questions concerning the hardware and software. I apologise in advance if some answer have already given. I spent lot of time (and headache) reading and surfing on the forum/site. 1) I read all and it opposite about cartridge. Some docs tell that they only exist 128K and 256K (AFAIK 32K exist obviously) and other tell that only 32K, 128K and 512K exist. Who to trust ? 2) In the same way, 32K is without mapper (0x8000 bytes length). But, Without mapper, we can access 0xC000 bytes of data, in other world 48K bytes of data. Do they exist 48K ROM ? 3) I try my SMS Reader on a simple 32Kb rom, "Super Tetris". The ROM chip have 16 bus address. I realy dont understand why : - To access 32K bytes, only 15 bus address is needed. - This ROM doesn't have Mapper, so the 0xFFFF doesn't need to be accessed. Why the ROM have this 16th bus address ? 4) I have assumed on my SMSReader that /RD and /RW pin are both LOW active (RD to 0 mean we read, or RW to 0 mean we write on ROM). I found some docs in contradiction with that. Who to trust ? 5) I don't understand the behaviour of /Mreq and /IOReq cartridge pin. Can you explain this to me ? 6) In the same way, on mapper, I don't understand the "ROM write" enable bit on register 0xFFFC. The write can only affect the cartridge RAM, no ? 7) If I understand correctly, the cartridge can set /BusReq to 0, and when the CPU answer with /BusAck setted to 0, the cartridge can for example write on address bus to read/write on system RAM ? (I ask this in order to make a cheat card) 8) I don't found any list of cartridge know to have separate mapper chip. Were to find it ? Thanks in advance !

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Tue Oct 25, 2016 9:11 am
	Hi, and welcome. 1. Cartridges exist at 32, 128, 256, 512 and 1024KB, but other sizes are possible. I think there might be a 64KB Game Gear game. 2. Not as far as I know. I think the manufacturing costs for 48KB may exceed that of 128KB, as it would require more chips. 3. The chip may be larger than 32KB internally? Or it's to make sure not to respond with the data from 0000 when 8000 is read. 4. The cartridge may not care about /WR. Almost everything is active low logic, but some docs may miss that important fact. 5. The Z80 (and many modern CPUs) has two buses it can address, memory and I/O. The latter is intended for peripherals, is used for everything except ROM, paging and RAM on the SMS, and is generally considered to only have 8 address lines (the upper 8 do carry some information but you need not care). It signals which one it is reading or writing using those lines, which then appear on the cartridge port. This allows the cartridge to correctly determine if it is ROM being read. 6. This is a testing feature for development boards and no known software actually uses it. 7. I guess so? It will mess with cartridge timing though... 8. It's not super well documented, the SMS Reader docs are the best we have. These days, "repro" makers are keeping their information close to avoid competion on the cartridges :) and I think there are not many games that are guaranteed to have a mapper inside. A homebrew cartridge would be much better.

leviatan Joined: 24 Oct 2016 Posts: 26	Posted: Tue Oct 25, 2016 10:01 am
leviatan Joined: 24 Oct 2016 Posts: 26	Thanks ! 1) Whoa ! 1024K ? very large ! (lol I'm stupefied by this big size, as I'm using 128Gb USB key.) 2) Yeah, manufacturing cost can explain this. 32K is a full address range ROM (15 addr bus) but 48K is a bastard adress range (16 addr bus stopping at 0xBFFF). The only way to cover 48K band is to use a 64K rom (48K rom doesn't exist), wich 16K unused. And 16K unused is a waste of money. Why don't I conclude this by myself ? 3) The chip I use to test my reader is, by test, effectively 32K large, not more. When accessing after 0x7FFF, the data is unclear and realy random, I can have different data at same location when reading multiple time. Its very likely the chip go on High Impedance (Hi-Z) mode on data line when accessing after 0x7FFF. You may be right, the 16th line address is here to prevent sending data, bus contention or mirroring after 0x7FFF 4) Thanks for confirm that fact. I assumed that 90% SMS logic work at low logic. Like 90% of electronic logic. The ROM I read have a /RW pin. on his chip. I assume that's for put data line in High Impedance if SMS want access FCR. 5) Strangely, the ROM I test have /Mreq and /IOReq left disconnected. 6) Hooo okay ! for debugging purpose ! That make sense ! 7) Yes, timming may be affected, of course. But the idea is here. 8) Mkay ! I will work with logic IC, building my own mapper will be a great challenge !

nitrofurano Joined: 01 Aug 2012 Posts: 322 Location: Porto, Portugal	Posted: Tue Oct 25, 2016 1:07 pm
	in theory, i imagine that the sms default pager would support 4mbyte roms (just like used from ascii16 pager from msx), but i guess no games larger than 1mbyte were manufactured in the 80’s and 90’s (and wouldn’t have support from most emulators because of that, i guess) - and some korean/taiwanese bootleg roms (conversions from konami’s msx games) would access 2mbyte roms (uses 8kbyte pages instead of 16kbyte) i guess also that, if 2 bytes were used for paging instead of 1, we would be able to access 1gbyte cartridge instead of 4mbyte only - the problem is how could we make this, from the homebrew scene, as a convention that would be supported on emulators, sd-cartridges, fpga clones, etc.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Tue Oct 25, 2016 1:22 pm
	Everdrive has a 1MB limit so that's a de facto limit for homebrew. Most emulators support 4MB. Any new mapper would take time to get support.

Flygon Joined: 30 Jun 2016 Posts: 196 Location: Melbourne, Australia	Posted: Wed Oct 26, 2016 12:12 am
	nitrofurano wrote i guess also that, if 2 bytes were used for paging instead of 1, we would be able to access 1gbyte cartridge instead of 4mbyte only - the problem is how could we make this, from the homebrew scene, as a convention that would be supported on emulators, sd-cartridges, fpga clones, etc. Going by what I've observed in the past, the kick in the pants that usually does it is a developer going ahead and making software for such a theoretical format. Assuming some sort of implementation of it exists at a hardware or emulator level, of course. Suddenly the interest in actually implementing support for the hardware that software uses erupts. Of course, this isn't an excuse to rush out ahead with poorly thought out hardware.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Wed Oct 26, 2016 8:28 am
	I believe Emulicious supports the db-electronics homebrew mapper which doesn't exist yet... I think what is needed is an actual hardware release of a decent game.

leviatan Joined: 24 Oct 2016 Posts: 26	Posted: Wed Oct 26, 2016 8:55 am
leviatan Joined: 24 Oct 2016 Posts: 26	I really don't understand the need of have a 1Gbyte storage cartridge.... If we want turn the SMS into a Computer I understand. Let's go back to the point : • Yesterday I finally test the /BUSREQ function. That work well ! So I stole all buses of the Z80 then I read by hard-wiring selecting 0xDC port the button states of my controller by conecting LEDs on DATA BUS. To select by hardware, I processed in this order (That's important, to avoid bus contention and short circuit) : - Connect a LED on /BUSACK (with resistor obviously, in sinking current, minus of led connected to the /BUSACK) - Connect 8 LEDs on the DATA BUS (with resistor obviously, in sinking current too) - Connect /BUSRECK to ground - Wait for the LED on BUSACK to bright (Approx 0.01 ms :) ) - Connect A0 to ground - Connect A6 and A7 to VCC +5V - Connect /IOreq and /RD to ground - Enjoy LED brighting by pressing button on controller ! Here is my observation : - BUSREQ can really stole safely all Z80 buses in order to use all SMS hardware, with custom hardware. - Obviously the Z80 "freeze", not pause ! he literally freeze at current PC. - DRAM was good enough to maintain data at last 5 big second safely. After too much time stilling buses, DRAM become unclear and the current game can become buggy, or restart at launching. I test this behaviour with the on-board game Alex Kid. So I couldn't test this point : The "Super Tenis" ROM I use to test my SMSReader is connected as follow : A0-A15, D0-D7, /RW pin, /CE pin. I don't understand why the /Mreq pin is not connected : When the CPU access to IOPort, HOW the rom know that it must free data bus ? The ONLY way to do that is that the IOPORT Chip who control /CEs lines free data buses by holding all /CEs up. Anyone can confirm that ?

nitrofurano Joined: 01 Aug 2012 Posts: 322 Location: Porto, Portugal	Posted: Wed Oct 26, 2016 10:09 am
	leviatan wrote I really don't understand the need of have a 1Gbyte storage cartridge.... If we want turn the SMS into a Computer I understand. 1: “because we can”! :D 2: even considering that a game wouldn’t take closer to 1gbyte (even a Myst remake! :D ), being able to produce rom files larger than 4mbytes, and not having silly constraints about rom size, seems interesting and provide some room for our homebrew creativity

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Wed Oct 26, 2016 10:25 am
	One thing I've considered is that with the right code, you can access the SD file system on the Everdrive, giving a lot of space at probably low speeds. Emulating that would be a pain, though.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Wed Oct 26, 2016 12:10 pm
	Maxim wrote I believe Emulicious supports the db-electronics homebrew mapper which doesn't exist yet... I think what is needed is an actual hardware release of a decent game. I still dream of an official SMS Power! collection cartridge with a few among the best homebrew we made here over the years, with a graphical boot menu for selecting the desired game. If we only could have the plastic shells we never found a way to have, we could surely convince db-electronics to add the needed bank-offsetting mapper feature. Still, I didn't give up on this.

NeonMan Joined: 24 Sep 2013 Posts: 141	Posted: Wed Oct 26, 2016 12:24 pm
NeonMan Joined: 24 Sep 2013 Posts: 141	cases are the easy (expensive?) part if you have a 3D printer. A catridge with a mapper is the hard part. I'm working on it ;)

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Wed Oct 26, 2016 12:32 pm
	well, actually we've got a suitable and feature rich cart since more than a year (see this video) but we still have no affordable way to shells :\|

leviatan Joined: 24 Oct 2016 Posts: 26	Posted: Wed Oct 26, 2016 1:00 pm
leviatan Joined: 24 Oct 2016 Posts: 26	Sorry but nobody can tell me if im right ? "The ONLY way to do that is that the IOPORT Chip who control /CEs lines free data buses by holding all /CEs up." Therefore, I see an immediate possibility to make a custom cartrige with 64, 128 Gbytes. By using SD card. We dont touch at the mapper at all. Ok so : - One classic mapper (covering all game possibility) - One 4Mib SRAM connected to the mapper, - One 32k SRAM connected to the mapper, - One MCU (Micro Controler Unit) connected to the Cartridge buses - One SD Card slot on the cardridge conected to the MCU. The Idea : In the SD, we have : - A custom BOOT ROM who list all ROMs wanted, - All wanted ROMs displayed at startup The custom BOOT ROM will write to RAM (a dedicated address, no mather if SMS DRAM or Cartridge SRAM) the choice of the user. We call this address ADDR_USER_CHOICE Functioning : - MCU : At startup, MCU immediatly hold buses with /BUSREQ. - MCU : load custom BOOT ROM in 4Mib SRAM. - MCU : release buses - SMS : take on and execute custom ROM. - SMS : Custom BOOT ROM display list of all game wanted. - MCU : Periodicaly, MCU hold buses to read ADDR_USER_CHOICE see if a choice was written on (for exemple, 0x00 no choice given, other number is the number of the game) - SMS : The user select a game, writted on ADDR_USER_CHOICE by Custom BOOT ROM - MCU : After the successful read of ADDR_USER_CHOICE, MCU keep buses holding in order to load wanted ROM into 4Mib SRAM. - MCU : Reset PC of SMS to startup, - SMS : take on and execute wanted ROM. That's my final goal.

leviatan Joined: 24 Oct 2016 Posts: 26	Posted: Mon Nov 07, 2016 10:27 am
leviatan Joined: 24 Oct 2016 Posts: 26	Hello all ! Somes news : I successfully used a SRAM as ROM cartridge for my master system. I don't have make a mapper, therefore and because I am limited to 32K, I loaded my previous awesome dumped Super Tennis game. That's work almost perfectly, but I need to disengage my custom cartridge to write on it. I must add Tri-State buffer to prevent SMS being in conflict when witting. I assumed that the original Super Tennis roms use the /M0-8 to set DATA pin in High-Z when accessing upper than 0x8000. I do the same with my SRAM chip by ORing the /RD, /M0-8 and /Mreq signals. The SRAM I used : AS6C4008. I ll test all these behaviours : - When CPU access IOPort, CE of the cartridge become Hight ? - When CPU access RAM (Upper than 0xC000), CE of the cartridge become Hight ? Do you know how to reset the CPU ? Must I do this in ASM (to reset the Program Counter and the IOChip) or there is an hardware solution ? The RESET pin of the cartridge port seems to be an OUTPUT, so we can't use it.

asynchronous Joined: 14 Aug 2000 Posts: 742 Location: Adelaide, Australia	Posted: Mon Nov 07, 2016 12:24 pm
	leviatan wrote Hello all ! Somes news : I successfully used a SRAM as ROM cartridge for my master system. I don't have make a mapper, therefore and because I am limited to 32K, I loaded my previous awesome dumped Super Tennis game. That's work almost perfectly, but I need to disengage my custom cartridge to write on it. I must add Tri-State buffer to prevent SMS being in conflict when witting. I assumed that the original Super Tennis roms use the /M0-8 to set DATA pin in High-Z when accessing upper than 0x8000. I do the same with my SRAM chip by ORing the /RD, /M0-8 and /Mreq signals. The SRAM I used : AS6C4008. I ll test all these behaviours : - When CPU access IOPort, CE of the cartridge become Hight ? - When CPU access RAM (Upper than 0xC000), CE of the cartridge become Hight ? Do you know how to reset the CPU ? Must I do this in ASM (to reset the Program Counter and the IOChip) or there is an hardware solution ? The RESET pin of the cartridge port seems to be an OUTPUT, so we can't use it. When reading or writing to an IO address, the Z80 CPU asserts (i.e. pulls low) the /IORQ line. When reading or writing a memory address, the Z80 CPU asserts (i.e. pulls low) the /MREQ line. So the 2 address spaces can co-exist without a problem. The /CE line on cart slot is the CPU /MREQ line AND-ed with the corresponding bit in the register mapped to IO port 0x3E. So /CE stays high when the CPU reads or writes to an IO address. The /CE lines do not take into account the CPU address. That means for a read or write to a memory address in the RAM address space (0xC000 to 0XDFFF) the /CE line on the Cart slot will go low. On early SMS the reset circuit was just a passive RC circuit. On later SMS and the SMS2 the reset circuit is buffered and driven by an output on IC4 which is what you're seeing. I haven't tested what it takes to pull the reset output to a logic low. Hope that helps.

leviatan Joined: 24 Oct 2016 Posts: 26	Posted: Mon Nov 07, 2016 1:43 pm
leviatan Joined: 24 Oct 2016 Posts: 26	Thanks for answer. Yes it really help me ! Maxim already explain to me the purpose of /Mreq and /Ioreq. You completed this explanation well ! My assumption was right. So I can use only /CE and don't care about /Mreq. This will save one logic gate. for the RAM address range, this is why the 15th address is used in the cartridge rom (in fact this is the /M0-8 pin). This is an "output enable" purpose to prevent bus contention. Same things for the /RD pin. I observe this behaviour when dumping my 32K rom. I didn't found ANY datasheet for the ROM used in this Super Tennis game, its not a Sega chip, I'm sure that this chip is in fact a simple generic 32K rom linked to complies with SMS. For the reset circuit... Mhhh I can't use that way. On RC circuit it's not a problem to go low, but on IC output its an other thing. With open-collector technologies it's fairly simple to combine two output, but I read that SMS is build with CMOS and its a really bad design to force an output to go low by that way. I don't want do a trashy patch, I must find a better way. Maybe by writing 0 to the bit 4 of $DD Port ? I think it can't be done, as the $DD port seems to be read only.

leviatan Joined: 24 Oct 2016 Posts: 26	Posted: Tue Nov 08, 2016 9:51 am
leviatan Joined: 24 Oct 2016 Posts: 26	Hi, I added Tri-State Bidirectional Buffer in data and addresses buses. That's work well, priority is correctly given to the MCU (Micro Controller Unit) when writing ROMs. So we can let the SMS running when writing on it. SMS become buggy as it can't read data, but there is no buses contention at all. A simple restart at end of writing and we can play game. My bidirectional buffers let the MCU access to all Z80 buses. I can hold buses, read or write on IOPorts or Memories. Im working on a very simple register with logic IC, holding only the FCR 0xFFFF. I read that almost all game only use that register. Can you confirm that ? The last thing where im stuck is how to reset the SMS. I want let the possibility to write a ROM then restart the SMS without turning it OFF then ON.

Forums

View topic - Noob on board