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 - Minimal 2Mbit memory mapper with PLD

Reply to topic
Author Message
  • Joined: 10 Dec 2009
  • Posts: 103
Reply with quote
Minimal 2Mbit memory mapper with PLD
Post Posted: Fri May 05, 2023 8:07 am
Hi. I wrote this little memory mapper with a g22v10 compatible PLD. You can swap only the 3rd page (8000-DFFF) writing to the ROM address space. Due to the pin number limit of this IC the flash dimension is 256KB (2Mbit).

Still not tried but I'm sharing it just to be sure that everything is correct.

I hope I'll receive some feedback about it and if it could works. 😁

https://github.com/siriokds/WinCupl-PLD-Examples/blob/main/ATF22V10C/MAPPER256.P...
  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 598
  • Location: London, UK
Reply with quote
Post Posted: Fri May 05, 2023 8:46 am
I guess you haven't actually synthesised this yet, since looks to be at least one typo - you reference a _MEMWR which doesn't exist at one point.

This doesn't look good to me:


/* Latch Data */
PAGE_A17.d = (D3 & PAGEWR) # PAGE_A17 & !PAGEWR;
PAGE_A16.d = (D2 & PAGEWR) # PAGE_A16 & !PAGEWR;
PAGE_A15.d = (D1 & PAGEWR) # PAGE_A15 & !PAGEWR;
PAGE_A14.d = (D0 & PAGEWR) # PAGE_A14 & !PAGEWR;


I think it might be cleaner to feed the inputs to your registers directly from the data bus and to make your clock input more complex. The gal devices only have a single global clock, so you'd need to implement some combinatorial logic to drive it, but it's just your PAGEWR signal I think you want. You could output that from the gal and connect that output to the clk input.

You should have spare outputs because I think either or both of your _FLASH_CS and _SRAM_CS are redundant as outputs.

On that note, I'm not really sure what _SRAM_CS would be for, as your mapper surely can't support cartridge RAM since it has no way of turning it off during boot.

Those are some initial observations, but regardless you really need to prototype and test as you can guarantee you'll find problems that no one, including yourself, will spot just from inspection of the design.
  View user's profile Send private message Visit poster's website
  • Joined: 10 Dec 2009
  • Posts: 103
Reply with quote
Post Posted: Fri May 05, 2023 9:28 am
I still wrote the code. Not synthesized yet.

Latch data part is working since I use it in another project. PLD language is a bit tricky for me, usually I wrote in VHDL. Flash/SRAM signals are used, I added it as chip selection logic. This mapper should be onboard onto an external cartridge as well as Flash and SRAM chips. SRAM is mapped only on the 4th page (C000-FFFF). _MEMWR was a typo. Corrected.



willbritton wrote
I guess you haven't actually synthesised this yet, since looks to be at least one typo - you reference a _MEMWR which doesn't exist at one point.

This doesn't look good to me:


/* Latch Data */
PAGE_A17.d = (D3 & PAGEWR) # PAGE_A17 & !PAGEWR;
PAGE_A16.d = (D2 & PAGEWR) # PAGE_A16 & !PAGEWR;
PAGE_A15.d = (D1 & PAGEWR) # PAGE_A15 & !PAGEWR;
PAGE_A14.d = (D0 & PAGEWR) # PAGE_A14 & !PAGEWR;


I think it might be cleaner to feed the inputs to your registers directly from the data bus and to make your clock input more complex. The gal devices only have a single global clock, so you'd need to implement some combinatorial logic to drive it, but it's just your PAGEWR signal I think you want. You could output that from the gal and connect that output to the clk input.

You should have spare outputs because I think either or both of your _FLASH_CS and _SRAM_CS are redundant as outputs.

On that note, I'm not really sure what _SRAM_CS would be for, as your mapper surely can't support cartridge RAM since it has no way of turning it off during boot.

Those are some initial observations, but regardless you really need to prototype and test as you can guarantee you'll find problems that no one, including yourself, will spot just from inspection of the design.
  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 598
  • Location: London, UK
Reply with quote
Post Posted: Fri May 05, 2023 9:48 am
siriokds wrote
Latch data part is working since I use it in another project. PLD language is a bit tricky for me, usually I wrote in VHDL.

Fair enough! Yeah likewise - I usually write in Verilog. (Win)CUPL is an absolute dog! I've done a few projects with those GALs and must admit I was never fully confident the HDL made sense until the circuit actually worked!

siriokds wrote
Flash/SRAM signals are used, I added it as chip selection logic. This mapper should be onboard onto an external cartridge as well as Flash and SRAM chips. SRAM is mapped only on the 4th page (C000-FFFF).

Okay, but how are you going to make sure that the system base RAM and your cart RAM don't try responding to read requests at the same time? You need some way of starting with cart RAM disabled so that the BIOS can boot without contention. You also then need some way in software of enabling your cart RAM, which I don't see in your HDL here.
  View user's profile Send private message Visit poster's website
  • Joined: 10 Dec 2009
  • Posts: 103
Reply with quote
Post Posted: Fri May 05, 2023 10:59 am
willbritton wrote
siriokds wrote
Latch data part is working since I use it in another project. PLD language is a bit tricky for me, usually I wrote in VHDL.

Fair enough! Yeah likewise - I usually write in Verilog. (Win)CUPL is an absolute dog! I've done a few projects with those GALs and must admit I was never fully confident the HDL made sense until the circuit actually worked!

CUPL is pain, but for tiny logic, I swallow it.

siriokds wrote
Flash/SRAM signals are used, I added it as chip selection logic. This mapper should be onboard onto an external cartridge as well as Flash and SRAM chips. SRAM is mapped only on the 4th page (C000-FFFF).

Okay, but how are you going to make sure that the system base RAM and your cart RAM don't try responding to read requests at the same time? You need some way of starting with cart RAM disabled so that the BIOS can boot without contention. You also then need some way in software of enabling your cart RAM, which I don't see in your HDL here.


There's a pin in the cartridge which, if tied to 5V, disable the internal (2KB) ram, so I can use the cartridge one (unluckly 32KB with 16KB wasted).
I should face no bus contention.
  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 598
  • Location: London, UK
Reply with quote
Post Posted: Fri May 05, 2023 11:13 am
siriokds wrote
There's a pin in the cartridge which, if tied to 5V, disable the internal (2KB) ram, so I can use the cartridge one (unluckly 32KB with 16KB wasted).
I should face no bus contention.

Are you designing for the (non-JP) SMS here?
I'm not aware of any input pin on the cartridge slot which disables RAM. Which of these pins do you think that is?
Internal RAM on the SMS is 8KB, not 2KB.
  View user's profile Send private message Visit poster's website
  • Joined: 10 Dec 2009
  • Posts: 103
Reply with quote
Post Posted: Fri May 05, 2023 12:21 pm
willbritton wrote
siriokds wrote
There's a pin in the cartridge which, if tied to 5V, disable the internal (2KB) ram, so I can use the cartridge one (unluckly 32KB with 16KB wasted).
I should face no bus contention.

Are you designing for the (non-JP) SMS here?
I'm not aware of any input pin on the cartridge slot which disables RAM. Which of these pins do you think that is?
Internal RAM on the SMS is 8KB, not 2KB.


I'm designing it for SG-1000/SC-3000
  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 598
  • Location: London, UK
Reply with quote
Post Posted: Fri May 05, 2023 12:26 pm
siriokds wrote
I'm designing it for SG-1000/SC-3000

Okay, then that makes a lot more sense!
  View user's profile Send private message Visit poster's website
Reply to topic



Back to the top of this page

Back to SMS Power!