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 - Development SMS unit

Reply to topic
Author Message
  • Joined: 05 Mar 2006
  • Posts: 53
  • Location: France
Reply with quote
Development SMS unit
Post Posted: Wed Apr 21, 2010 9:14 pm
Last edited by furrtek on Thu Apr 22, 2010 9:39 am; edited 1 time in total
Here's the idea:
Add an "embedded" 512k SRAM cartridge to the expansion port of a SMS1, and write a new bios to allow code upload and execution via the joypad ports.
For now I only have a draft schematic and a partialy commented dump of the original v1.3 bios (just noticed that Bock already did it...). I'm replacing it with a 32Kb flash chip.
The board itself would contain 4 128KB piggy-backed SRAM chips with their CE lines connected to a 2 to 4 decoder, itself connected to the A17 and A18 of a real Sega 315-5235 mapper.
I'm now wondering if some code copied by the bios in RAM would be able to simply write to the SRAM just by activating the exp slot, doing some LD (HL),A's and taking care of the paging. Set ($C000) correctly and then jump to $0000 like the real bios does...
All this by keeping the "TMR SEGA", checksum, regions checks and boot priorities for all the 3 slots.

I know there's already the SMSReader and Tototek flash solutions, but none of them enables someone to quickly upload some code and execute it only by pressing a key (F9 to compile, F10 to run in emulator, F11 to run for real).

It might not be a very useful mod 24 years after the console was released, but documenting the process and pointing out pitfalls could maybe help people interested in adding "integrated" dev memory to old systems.

So, do you think it's worth the effort ? Are there any obvious obstacles I'd have missen ?

PS: The VDP is seriously hot, but the video and sound outputs are okay. Is that normal ? I don't know if that's since I've changed the bios.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14690
  • Location: London
Reply with quote
Post Posted: Wed Apr 21, 2010 9:47 pm
What data rate can you get over the control port? Can you get suitable SRAM chips?
  View user's profile Send private message Visit poster's website
  • Joined: 25 Dec 2005
  • Posts: 607
  • Location: São Paulo - Brazil
Reply with quote
Post Posted: Wed Apr 21, 2010 9:58 pm
I have no clue how you pulled this up, but if I got it right this I have some questions:

how are you linking to the dev pc ? USB 2 "serial" (control port) ?
how would one "upload" code using this link ?

Also, I think it was already discussed here about how it isn't viable to run code directly from the PC, but Maxim's adressed that now.
  View user's profile Send private message
  • Joined: 05 Mar 2006
  • Posts: 53
  • Location: France
Reply with quote
Post Posted: Wed Apr 21, 2010 10:35 pm
The SRAM would be some TC551001's, they're fast enough for reading and writing.

For the data rates, I'll have to make some tests when the first chip and minimal bios will be working.
If RS232 is too hard to handle, I'll go with the parallel port (rx,tx,clock). And if it's still too slow, maybe I can try adding bus switches and an µC to poke directly in the SRAM with the full 8 bits of the parallel port. Kind of like an EPROM emulator.

It could work by first sending the binary size to be uploaded, then packets of 256 bytes or less + checksum. If the check fails, the same packet is sent again x times before giving an error.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14690
  • Location: London
Reply with quote
Post Posted: Thu Apr 22, 2010 12:25 am
With a bus switch you could have a full-on USB connection via a uC and avoid the parallel port reliance - that being a major problem for homebrew hardware these days.

It could also control the SMS (asserting HALT and pulsing RESET, I guess) for uploading and playing while the system's powered on (?); and perhaps support higher-rate writing than the host software could achieve.

Anyway, a custom BIOS could indeed load code to RAM that picks up bits from the controller port (better parallel than serial, I guess) and writes them to the expansion port RAM. $c000 support isn't super important unless the game needs to use port $3E, and even then some commercial games ignore it. Checking for TMR SEGA etc isn't really necessary (and slows things down), I'd detect using the Japanese BIOS method (test for data variation, assuming unconnected ports read back constant values).

512KB is 50% too small to support all commercial games, if you care about that.

Would you be using a scavenged paging chip or homebrewing it?
  View user's profile Send private message Visit poster's website
  • Joined: 05 Mar 2006
  • Posts: 53
  • Location: France
Reply with quote
Post Posted: Thu Apr 22, 2010 8:53 am
I guess I'll try the joypad port method first, and if everything goes well, add an usb PIC, shift registers and latches to get rid of the parallel port connection.

What do you think about first doing the data variation test, and continue with the "critical" tests if the slot in question isn't empty? To spare time, but to keep things right like if the code was running with a normal bios.

I'll stick with 512KB, as I only have 6 SRAM chips and no way to program CPLDs for now.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14690
  • Location: London
Reply with quote
Post Posted: Thu Apr 22, 2010 10:58 am
The data variation test means you don't have to have a valid header/region/checksum - keeping these up to date will be more work than otherwise, and may be impossible (e.g. patching an SG-1000 game that uses the $7ff0 region for something important).

A full checksum test takes a significant amount of time - I think about 1s per 64KB, as a rough guess - which presumably explains why many 512KB games only checksum the first 256KB. Better I think to either

- allow free selection of the slot (as in SMS Boot Loader
- Do data detection, then list on-screen the info on the contents of the slots - something like:

   Slot  Data Header   Checksum  Region Size

-> Cart  Yes  TMR SEGA 12AB Pass Exp    256KB
   Card  No   ........ FFFF Fail ....   ....
   Exp   Yes  NAKA.... 0000 Fail Jap    32KB
   Copy from Joy2 to Exp

(but made to fit in 32 columns). The checksums could be calculated "asynchronously" (i.e. filled in when calculated but allow slot selection at any time). You could also auto-boot when only one slot is valid, or apply slot priority rules, or allow a button press to force or suppress auto-boot. Obviously the first option is simpler :)

I don't think you should make it boot games like a regular BIOS - it's a power user feature, give us all the options and/or info; but it's good to make sure the cart has a good connection, hence the checks.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Mar 2006
  • Posts: 53
  • Location: France
Reply with quote
Post Posted: Thu Apr 22, 2010 11:53 pm
Thanks for your advice. Your screen layout kind of looks like the one I was planing to do, with one line for each slot, but more detailed. I'll add all the details you talked about.



For the joypad poll during the checksums calculations, I guess It has to be implemented in the checksum routine loop since interrupts (read port $DC each VBL) can't be used while other slots are activated ?
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14690
  • Location: London
Reply with quote
Post Posted: Fri Apr 23, 2010 6:10 am
furrtek wrote
For the joypad poll during the checksums calculations, I guess It has to be implemented in the checksum routine loop since interrupts (read port $DC each VBL) can't be used while other slots are activated ?

Yes, or you could make the checksum routine only check (for example) 1KB at a time (whatever fits comfortably in a frame), and expect to be executed multiple times until done, restoring the BIOS ROM after each chunk. Then just di/checksum/ei and vblank interrupts can stay on.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Aug 2000
  • Posts: 740
  • Location: Adelaide, Australia
Reply with quote
Development SMS unit
Post Posted: Fri Apr 23, 2010 5:07 pm
If I have understood correctly, you want to send commands and data from a PC to the SMS via one of the controller ports right? Yeah it's possible I think.

I experimented and wrote some asm a while back to see what sort of transfer rate could be achieved over a controller port in theory. I think from memory 40kB/sec sustained looked possible using a parallel nibble transfer with handshaking. Not tooooo bad (but not great either). The polling of the port, IO transfers, packing the received nibbles, adding the protocol timeouts all add up and slow the achievable speed down.

Such a cable/dev system is possible and would allow you to download an executable to the target (that is, the connected SMS) and run it. But anything more specialised like instruction step and breakpoints would be out a more specialised design. Still this is all some people want to be able to do!

Yes, the VDP does run very warm/hot to the touch.
  View user's profile Send private message
  • Joined: 05 Mar 2006
  • Posts: 53
  • Location: France
Reply with quote
Post Posted: Sat Apr 24, 2010 1:12 am
Maxim: so if the timing is right, and assuming only the VBL interrupt is enabled, there's no need to di before and ei after ?
Each time the checksum routine RETs in the BIOS code, it would have to wait for a "VBL interrupt done" flag to call the routine again and keep the timing correct. Or am I missing something ?

Asynchronous: that's it, and I'm still torn between keeping the hardware simple and doing transfers by the joypad ports, or take advantage of usb and bypass the SMS's hardware. 40kB/s seems not to bad to me also. Anyways, the two solutions can be both used without changing anything.

Here's the unfinished schematic of the board to be connected to the expansion port: http://furrtek.free.fr/noclass/smsdev/smsdb1.jpg
It's quite messy and a few lines are still missing, but as I'm not very experienced in that kind of design, I'd like some opinions on it before getting too far.
The mapper chip isn't represented yet, only the address lines coming from it are on the AMAPPER connector.
I'm also not too sure about using the HC245 to isolate the data bus (which needs to be kept bidirectional to the SRAMs, of course).

Here's how I'd see the board fit: http://furrtek.free.fr/noclass/smsdev/pcbpl.jpg

Okay, so VDPs are known to heat up. I was worried it was missing a ground connection or something. And speeking of heat, I wonder if the added board would make the total current consumption exceed the 1A rating of the 7805...
  View user's profile Send private message Visit poster's website
  • Joined: 28 Sep 1999
  • Posts: 1197
Reply with quote
Post Posted: Sat Apr 24, 2010 9:01 pm
Quote
I'm also not too sure about using the HC245 to isolate the data bus (which needs to be kept bidirectional to the SRAMs, of course).


The Z80 is NMOS so I would suggest using HCT parts between all CMOS chips on your board and Z80 signals. A 74HCT245 on the data bus would be fine.

In my design the Z80 directly controls a DLP Design USB245M module (you could buy a FTDI FT245R chip too) for USB communication, and it is fast enough to load 512K of SRAM with game data in several seconds. The PIC idea is very cool, but the Z80 could do the same work I think?

The HC parts use very little power so I doubt the current draw will increase much if it is mostly HC/HCT parts. You could always add your own 7805 to the board if you were worried. :D
  View user's profile Send private message Visit poster's website
  • Joined: 05 Mar 2006
  • Posts: 53
  • Location: France
Reply with quote
Post Posted: Sat May 15, 2010 5:02 am
The FT245 is very interesting :) Didn't even imagine a chip like that would exist.
I bought a PIC 18F2550 for the tests but I'll certainly buy the FTDI chip if I end up making a definitive version, and leave the Z80 do all the work, like you said.
I'll try to use only HCT parts, or at least HC if they're hard to get in surface mount packages.
The board layout is starting to become a nightmare, 5x12cm is just too small for all those address lines...

The BIOS looks like this for now:

(no data detection and no checksum verification)

I had troubles accessing the VDP without any delay at start up.
The original BIOS goes through a (long) delay loop before sending anything to it, and the official GG docs states that the VDP is sometimes left in reset when the Z80 is already running. Waiting for $B0 on port $7E got rid of the problem without using a delay loop.

But another problem appeared: writes to port $3E weren't doing anything, so it still has to go through a (faster) delay loop before using it. This seems weird because the I/O chip shares the same reset line than the VDP and Z80... could those delays be caused by different threshold voltages between the chips and the charging curve of the capacitor on the reset line ?

(Edit: thinking about something like that, especially with 0.8s to get to VCC/2...)


A few issues also with the SRAM I tried on the exp slot: it doesn't seem to release the bus fast enough some times, and hangs everything after being checked. I'm following the original BIOS method to use port $3E, so I guess it's the chip's or the wires fault.
dbiosrl1.jpg (51.43 KB)
Attachment fairy
dbiosrl1.jpg
smsreset.jpg (31.78 KB)
smsreset.jpg

  View user's profile Send private message Visit poster's website
  • Joined: 28 Sep 1999
  • Posts: 1197
Reply with quote
Post Posted: Sat May 15, 2010 8:00 am
Quote
But another problem appeared: writes to port $3E weren't doing anything, so it still has to go through a (faster) delay loop before using it. This seems weird because the I/O chip shares the same reset line than the VDP and Z80... could those delays be caused by different threshold voltages between the chips and the charging curve of the capacitor on the reset line ?


Looking at the schematics it uses a 100K resistor and 10uF capacitor, so the reset time is one second. That seems quite long but fits your measurements nicely.

It seems possible that the chips exit their reset state at slightly different times -- if you have a long enough delay (say equal to how much time the BIOS takes up before touching port 3E), does port 3E always work? Or do you need a longer delay than normal?

Quote
A few issues also with the SRAM I tried on the exp slot: it doesn't seem to release the bus fast enough some times, and hangs everything after being checked. I'm following the original BIOS method to use port $3E, so I guess it's the chip's or the wires fault.


What is the part number and speed of the SRAM you are using?

The BIOS is looking great!
  View user's profile Send private message Visit poster's website
  • Joined: 05 Mar 2006
  • Posts: 53
  • Location: France
Reply with quote
Post Posted: Sat May 15, 2010 12:44 pm
Port $3E seems to always work after a $4*$4000 loop (didn't do any precise time measurement, but it's at least 3 times shorter than the BIOS delay).
I'll change the resistor and see if the delay can be shortened. I found the time constant kind of long also :/

The SRAM is a TC551001, /OE to the sms's /RD, /CE1 to /CE, CE2 to VCC, R/W to /WR.

Here's the source if you really have free time: http://furrtek.free.fr/noclass/smsdev/dbios10.asm
The delay routine is "pause".
"SRAMCheck" attempts to do writes and reads on the first 32kB, and stores the last error's address in ($C001). No errors when the SRAM actually leaves the bus soon enough.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Aug 2000
  • Posts: 740
  • Location: Adelaide, Australia
Reply with quote
Development SMS unit
Post Posted: Sat May 15, 2010 2:43 pm
What you described above about the SRAM is different from your schematic you posted a link to.

Quote
The SRAM is a TC551001, /OE to the sms's /RD, /CE1 to /CE, CE2 to VCC, R/W to /WR.


From your schematic I can see you're using a NAND gate to invert the Z80 /MREQ line to drive the CE lines of all the TC551001's and you're using a 74HC139 with the enable line grounded to create the 4 separate /CE for the TC551001's. The problem with doing that is one of the TC551001 will always be enabled when the SMS DRAM is enabled and you'll have bus contention. The same will happen if the Exp slot /CE line is used instead of the /MREQ line and the CE lines are tied high.

If you're using the /MREQ line or SMS generated /CE line to enable your SRAM then you need some additional logic to not enable for 0xC000 - 0xFFFF of the Z80 memory space.

If that's not your problem then I'd check for bad connections or loose wire or mistakes in the build. I don't think the problem will be the fast 70/85ns TC551001 on the snail-pace Z80 3.58MHz bus.

Hope that helps.
  View user's profile Send private message
  • Joined: 05 Mar 2006
  • Posts: 53
  • Location: France
Reply with quote
Post Posted: Sat May 15, 2010 4:13 pm
It helped a lot, thanks ! I didn't built the entire thing, but the problem was the same.

Didn't think of disabling the SRAM when the address is greater than $BFFF.
I thought the /CE line from the slot was held high in that range, but now that I think about it, it would make writing to cart ram impossible...
So I ANDed A14 and A15, ORed the result with /CE and fed it to the SRAM's /CE1. Works great :)
I'll try uploading stuff to it tonight.

About the different reset times: no more delay loop necessary to use port $3E with a 10k resistor.
  View user's profile Send private message Visit poster's website
  • Joined: 27 Oct 2009
  • Posts: 138
Reply with quote
Post Posted: Tue Jun 01, 2010 4:33 am
You could have "break on button" support if you are "Running on real machine" though. Would just need to add a detection routine in your interrupt handler, would be handy if you wanted to say, dump registers/RAM. A more sophisticated device could perhaps watch the BUS for access to a particular memory address and break on it. Allowing user BPs.

I like this project though furrtek. Simplifying the build process on the real machine is something that needs to be done at some stage. Perhaps even working together with an emulator, say you "break" on PC and it loads the real SMS state into an emulator, allowing you to look at the tiles/reg/etc. I would be willing to help with this.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Mar 2006
  • Posts: 53
  • Location: France
Reply with quote
Post Posted: Wed Jun 02, 2010 2:38 pm
Great to know you're interested in this project :) I don't know how far I am behind you about electronics knowledge, but I hope it won't get too much in the way to get things done (my English is sometimes a little awkward too, sorry about that).

I'm currently putting money aside to start using CPLDs (looking at Lattice's ispLSI devices), and trying to get the PIC18F2550's usb to work.

I'm not sure about how to do "hardware BPs". I was thinking about serially loading the addresses from the PIC to the CPLD, so it can halt the cpu and trigger an int on the PIC, but the PIC would then have to read the address bus itself to know which one of them was reached...
I tried searching documents about Intelligent Systems dev hardware but all I got was pcb pictures (they mostly use FPGAs and DRAM).

If you have time, what would be the easiest way to do collaborative editing on schematics/design notes for you ?
  View user's profile Send private message Visit poster's website
  • Joined: 29 Aug 2010
  • Posts: 1
Reply with quote
Post Posted: Sun Aug 29, 2010 3:41 pm
Sorry for the thread hijack.

What I have done (on a master system 2) is pulled the bios, replaced it with a socket to mount my protoboard, and then on the protoboard, connected in parallel, the bios chip, a 4-MBit SRAM chip, and an ATMega128. The ATMega128 is also tied to the Z80's reset line. When I want to drive the bus, I hold the Z80 in reset. I can transfer an image via a serial connection, using XModem-CRC (which should be available in just about any terminal program) to the ATMega128, which programs it into the SRAM chip.

It's not fully functional yet, Ideally I want to be able to select either the BIOS chip or the SRAM for operation by the CPU, but I haven't wired that up properly yet, and I haven't finished the code for the ATMega128 properly, at the moment its not driving puttng the SRAM control lines (/OE, /CE, /WE etc etc) into the correct state for it to be accessable to the CPU.

What I'm lacking, is a mapper chip. I'm looking into using a CPLD to do this, I saw this thread, and was wondering if anyone had actually tried the mapper.

I was also curious about using the /HALT line, my glance at the datasheet for the Z80 suggested that the /HALT line was an output only, indicating that a HALT operation had been executed. I don't have the data sheet handy, but the pinout here implies again that it is an output, not an input.
  View user's profile Send private message
  • Joined: 12 Apr 2005
  • Posts: 391
  • Location: London, United Kingdom
Reply with quote
Post Posted: Mon Aug 30, 2010 1:55 am
Maxim may have meant /WAIT, which will suspend execution when asserted (though this is intended for use with slow memories or I/O devices). The best way to take control of the buses is to assert /BUSREQ and wait for the Z80 to pull /BUSACK low.

I use an ATmega644P as an I/O controller with a Z80 and it works rather nicely. I have a flip-flop on /IORQ which automatically asserts /WAIT (the AVR would not have time to respond to /IORQ otherwise) which is reset once the AVR has done what it needs to. I use /BUSREQ and /BUSACK to perform DMA transfers between the AVR and the SRAM when requested.
  View user's profile Send private message Visit poster's website
  • Joined: 06 Aug 2010
  • Posts: 20
Reply with quote
Post Posted: Mon Sep 13, 2010 9:20 am
How hard would it be to get the atmega to catch a write to, say 0xFFFC to 0xFFFF?
And then DMA write to ram.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14690
  • Location: London
Reply with quote
Post Posted: Mon Sep 13, 2010 11:08 am
You mean to implement paging by copying data? That would be far too slow.
  View user's profile Send private message Visit poster's website
  • Joined: 06 Aug 2010
  • Posts: 20
Reply with quote
Post Posted: Mon Sep 13, 2010 12:57 pm
Not if you develop for it.
I am thinking of a develop cartridge that is using ram and a serial port for upload of data.
  View user's profile Send private message
  • Joined: 14 Aug 2000
  • Posts: 740
  • Location: Adelaide, Australia
Reply with quote
Development SMS unit
Post Posted: Thu Sep 16, 2010 6:40 am
Copying is one thing, paging during run-time is another. Even a 20MHz ATMEGA would be too slow to handle paging on it's own. A single instruction takes 50ns at that clk.
  View user's profile Send private message
  • Joined: 05 Mar 2006
  • Posts: 53
  • Location: France
Reply with quote
Post Posted: Tue Aug 02, 2011 2:29 am
Last edited by furrtek on Tue Aug 02, 2011 4:35 pm; edited 1 time in total
Hey,
Sorry for digging up this topic, but I got back to my SMS stuff recently to have a bit of fun during the holidays.
I was sure that someone had already done a RAM cart over here, so I didn't bother checking the forum before to avoid getting discouraged, and went through the build.



The only question I have: Is it normal that the mapper keeps driving his address outputs even when his /CE is high ?
Got a bit scared when I saw that A14~A16 were at 0.5V when the µC was supposed to put them high...
schema_full.png (41.49 KB)
Attachment fairy
schema_full.png
pcbback.jpg (64.82 KB)
pcbback.jpg

  View user's profile Send private message Visit poster's website
  • Joined: 28 Sep 1999
  • Posts: 1197
Reply with quote
Post Posted: Tue Aug 02, 2011 5:34 am
Quote
The only question I have: Is it normal that the mapper keeps driving his address outputs even when his /CE is high ?
Got a bit scared when I saw that A14~A16 were at 0.5V when the µC was supposed to put them high...


Yes, it's normal. The mapper chip always drives the banked address line outputs, they are never tri-stated.

Do you need to have the MCU drive the address lines, and that's what the series 1K resistors are for? You could also use a 74HC157 multiplexer to route either the MCU I/O pins or the mapper address lines to the RAM.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Mar 2006
  • Posts: 53
  • Location: France
Reply with quote
Post Posted: Tue Aug 02, 2011 4:32 pm
Yes, the MCU does all the work while the SMS is in reset state, so it needs to drive the RAM chip directly. The MCU could have used the mapper too, but I wanted to keep everything very simple.
Everything runs fine so I guess the resistors aren't causing that much of a problem.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14690
  • Location: London
Reply with quote
Post Posted: Mon Apr 11, 2022 9:57 pm
The DBIOS image is now here:

https://www.smspower.org/Homebrew/DBIOS-SMS
  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!