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 - Bit-banging and Cartridge Dumping

Reply to topic
Author Message
  • Joined: 14 Aug 2000
  • Posts: 643
  • Location: Adelaide, Australia
Reply with quote
Bit-banging and Cartridge Dumping
Post Posted: Thu Jun 03, 2021 1:42 pm
TLDR version:

I wrote a test program that can dump a Cartridge using the Master System by bit-banging the data through a controller port using only a TTL-RS232 converter board ($3.00), a USB-Serial Port cable ($5) and PuTTY (free).

Super Long version:

Last year I was developing my own BIOS for the Master System as a pre-cursor to some game development and possibly as a submission to the Coding Comp. The BIOS was going to have some special features such as dumping a cartridge through the controller port by pressing a button combination (DOWN+1+2) and using the software to bit-bang it through the controller port in lieu of any sort of UART or serial communications capability on the Master System. Seeing the quality of the Coding Comp submissions, the availability of dumping hardware circa $100USD, some of which are elegant solutions, and also having way too much on my plate, the idea seemed lame, and I shelved it.

Until last week when there was some interest in cartridge dumping solutions in another topic on the forum and I also came across some left over TTL to RS232 converter PCBs at work from an old, legacy project.

The goal is straight forward: be able to dump a card or cartridge using the Master System itself for maximum compatibility without the need for special or costly hardware and software other than a cheap level converter.

I’m not the first person to think of bit-bang serial communications through the Master System controller port. I believe someone has done it on these forums before but I haven’t seen the details of their solution (sorry I can’t remember your name).

So after successfully sending “Hello World” to PuTTY on my laptop at 4800 baud, then 9600, 19200, 38400, 115200, I wrote a simple test routine to read a 32KB cartridge and transmit it though the controller port at 115200 baud. And it worked.

It takes just under 9 seconds to dump a 32KB cartridge. I’m using PuTTY to receive and save the serial data as a file which is working well.

The real moment of truth was running a file comparison between the received PuTTY log and a dump of Super Tennis which I used as a test cartridge and getting a match:

fc /b STENNIS.SMS putty_log.txt
Comparing files STENNIS.SMS and PUTTY_LOG.TXT
FC: no differences encountered 



The program is very much still in development phase and is nowhere near ready for release, but support for larger cartridges and adding user-friendly features like automatic size detection of cartridges (you can’t rely on the ROM Size value in the software header for actual cartridge size) and a GUI aren’t too hard a task.

Somewhere down the track a physical release on a MyCard or a dirt cheap ‘Dumping Kit’ of some sort consisting of MyCard and TTL to RS232 dongle would be ideal.

Anyhow, I’m happy with the results so far and the potential. I not bothered everyone thinks this is lame and it gets no interest. I was a geek long before it was cool to be a geek :)
DSC_2842.JPG (102.92 KB)
DSC_2842.JPG
Putty_Log_XVI32.png (89.03 KB)
Putty_Log_XVI32.png

  View user's profile Send private message
  • Joined: 27 Jun 2020
  • Posts: 201
Reply with quote
Post Posted: Thu Jun 03, 2021 1:47 pm
Legendary! following this for sure!


My latest Idea after seeing the quality of some of the MSX2 games is a mainboard that can play both MSX2 / MSX and SMS/ SG1000 / SC3000 games. Check out the quality of the metal gear games and the castlevania which NES got but master system didn't - unfortunately being MSX2 they can't be ported without hardware upgrades.

Looking forward to future updates on this project - adding to my bookmarks toolbar.
  View user's profile Send private message
  • Joined: 14 Apr 2013
  • Posts: 552
Reply with quote
Post Posted: Thu Jun 03, 2021 1:58 pm
asynchronous wrote
I’m not the first person to think of bit-bang serial communications through the Master System controller port. I believe someone has done it on these forums before but I haven’t seen the details of their solution (sorry I can’t remember your name).

I believe what you're thinking of is N0RamBoot by NeonMan?:
https://www.smspower.org/forums/17134-SerialBootloaderNowWithWholeRAMUsageAndVRA...
  View user's profile Send private message Visit poster's website
  • Joined: 27 Jun 2020
  • Posts: 201
Reply with quote
Post Posted: Thu Jun 03, 2021 2:12 pm
Can we get a release as just a self booting BIOS as well? then we can use version 2 master system.

And if we use BIOS instead of card we could also dump card based games off the model 1.

Or even (not sure if possible) like a pass through cartridge, so a cartridge with your app which would be very small, it could load the important parts into system RAM then maybe have a switch on it if need be that sort of kills it once you select "dump rom"... and on top of the cart a female 50pin connector for the cartridge you want to dump to go on.

Like make your selection

*dump rom though controller port 2
...
Pleas flick switch

(then you flick the switch and hit ok)

Then program starts dumping


**I thought about this for a while and it should be totally possible

Just pass through all the pins into the second cartridge on top of your cartridge with your dumping tools - then toggle power between each cartridge, although knowing you programmers you'd already have thought of a way to do this with a software switch and some discrete IC addition as oppose to a manually flicked switch.
  View user's profile Send private message
  • Joined: 22 Apr 2018
  • Posts: 385
Reply with quote
Post Posted: Thu Jun 03, 2021 3:42 pm
This could make a great extra menu option in an Action Replay cartridge
  View user's profile Send private message
  • Joined: 14 Aug 2000
  • Posts: 643
  • Location: Adelaide, Australia
Reply with quote
Bit-banging and Cartridge Dumping
Post Posted: Fri Jun 04, 2021 8:50 am
@Calindro – yes that’s the one.

@L10N37 – they’re all good ideas, but pass-through cartridge adapters with specialised electronics, which can be done, increase the cost, which defeats the goal of a dirt cheap and readily available method of dumping. About the switch on a cartridge adapter; I have a couple of those third party SMS->MD adapters where the pause button is on the adapter. You can’t actually use the pause button because the slightest movement can cause the game to crash.

@bsittler – not a bad idea.
  View user's profile Send private message
  • Joined: 14 Aug 2000
  • Posts: 643
  • Location: Adelaide, Australia
Reply with quote
Bit-banging and Cartridge Dumping
Post Posted: Fri Jun 04, 2021 12:18 pm
Small Update:

Re-wrote part of the test program in my lunch break today.

32KB Cartridges are now dumped in about 4.5 seconds.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13812
  • Location: London
Reply with quote
Post Posted: Fri Jun 04, 2021 7:43 pm
Another idea: compute the CRC of the ROM and display it, maybe also look it up in a list to say if it’s known or not. No need to transfer a known ROM :)
  View user's profile Send private message Visit poster's website
  • Joined: 14 Oct 2008
  • Posts: 398
Reply with quote
Post Posted: Fri Jun 04, 2021 11:10 pm
Maybe, it would be good to add some kind of test that there isn't a connection problem before saying it isn't a known ROM. If that can be done.
  View user's profile Send private message
  • Joined: 22 Apr 2018
  • Posts: 385
Reply with quote
Post Posted: Sat Jun 05, 2021 1:21 am
KingMike wrote
Maybe, it would be good to add some kind of test that there isn't a connection problem before saying it isn't a known ROM. If that can be done.


Reading a section of the ROM a few times and ensuring the reads match each other can give confidence. Also more confidence if each bit position in bytes is seen in both set and cleared states somewhere in the ROM, and if the ROM data isn't purely repetitive over any power-of-two period in the range from two byte period up to 8 kB period (or stop sooner of course if one of the few known smaller ROM images is identified). Together these checks provide some confidence that the data lines and most of the address lines are working.
  View user's profile Send private message
  • Joined: 14 Aug 2000
  • Posts: 643
  • Location: Adelaide, Australia
Reply with quote
Bit-banging and Cartridge Dumping
Post Posted: Wed Jun 09, 2021 2:10 pm
*UPDATE*:

After some more optimising I got the transfer rate down to about 3.5 seconds for a 32KB cartridge.

Minor improvements to the transfer speed beyond this are possible, but it’s a case of diminishing returns.

I added functionality to dump 128KB and 256KB cartridges based on the ROM Size value in the game's software header for testing purposes. 128KB cartridges are dumped in about 14 seconds and 256KB cartridges in about 28 seconds. None of the 512kB game I own report a ROM Size of 512kB in the header so I wasn’t able to dump a 512KB cartridge for testing.

The dumps all passed the checksum check and loaded in an emulator running the v1.3 BIOS just by renaming the PuTTY log file extension to sms.

PuTTY has been very reliable to save the stream of bytes to a file. I’m just using the standard ‘log all session output’ option with no special settings or scripts and it’s working quite well and giving complete and consistent dumps over and over again.

Such simplicity with no flow control or guaranteed delivery does come at a cost though. Having a few File Explorer windows and cmd open during the transfer gave no problems. But Chrome or excel maximized caused Putty to drop bytes, especially in the first few minutes of opening the app when the app is doing a few things in the background like checking for updates etc.

None the less though, I consider the Proof of Concept - using the SMS itself and cheap and free off-the-shelf hardware and software to dump games - complete and moving on to developing the Master System program.

I have to warn you all though, I adopt an Agile approach, so my development is incremental and when I can fit it in. So patience.

Oh and I intend on roping in you first-responders in for UAT down the track. 😊

More updates to come...eventually.
DSC_2843.JPG (388.25 KB)
DSC_2843.JPG

  View user's profile Send private message
  • Joined: 25 Nov 2015
  • Posts: 135
Reply with quote
Post Posted: Thu Jun 10, 2021 8:03 am
asynchronous wrote
*UPDATE*:

After some more optimising I got the transfer rate down to about 3.5 seconds for a 32KB cartridge.

Minor improvements to the transfer speed beyond this are possible, but it’s a case of diminishing returns.

I added functionality to dump 128KB and 256KB cartridges based on the ROM Size value in the game's software header for testing purposes. 128KB cartridges are dumped in about 14 seconds and 256KB cartridges in about 28 seconds. None of the 512kB game I own report a ROM Size of 512kB in the header so I wasn’t able to dump a 512KB cartridge for testing.

The dumps all passed the checksum check and loaded in an emulator running the v1.3 BIOS just by renaming the PuTTY log file extension to sms.

PuTTY has been very reliable to save the stream of bytes to a file. I’m just using the standard ‘log all session output’ option with no special settings or scripts and it’s working quite well and giving complete and consistent dumps over and over again.

Such simplicity with no flow control or guaranteed delivery does come at a cost though. Having a few File Explorer windows and cmd open during the transfer gave no problems. But Chrome or excel maximized caused Putty to drop bytes, especially in the first few minutes of opening the app when the app is doing a few things in the background like checking for updates etc.

None the less though, I consider the Proof of Concept - using the SMS itself and cheap and free off-the-shelf hardware and software to dump games - complete and moving on to developing the Master System program.

I have to warn you all though, I adopt an Agile approach, so my development is incremental and when I can fit it in. So patience.

Oh and I intend on roping in you first-responders in for UAT down the track. 😊

More updates to come...eventually.


DIRTY CHEAP ! I LOVE IT !!
  View user's profile Send private message
  • Joined: 27 Jun 2020
  • Posts: 201
Reply with quote
Post Posted: Sun Jun 13, 2021 5:37 pm
That's awesome! They even sell extension cables for megadrive controllers on the cheap that you could hack up. Can't wait until this is finalised.. will have one in a nice project case for sure.

With putty that's pretty normal. I forget I've got my miner going sometimes and I'll be doing a million things at once.. things can go wrong. It's like when you burn a CD.. you want to close everything off and just walk away until it's done. Browsers are always pretty brutal (been on waterfox for many years now)

Wouldn't blame putty as such.
You may need to list minimum requirements PC spec wise lol

Also with the dumping, maybe the master system would be better off with a manual setting as well as with auto by header check. On manual mode you could maybe have it dump continuously on a timer to a buffer on the PC side then have the software on the PC end do some magic and dump the correct range from the buffer into a file? I don't know how hard this would be but it would simplify things on the console end. I would assume an overdump would easily be detectable and a time for streaming easy to calculate (at least long enough to do a 512kb game)
  View user's profile Send private message
  • Joined: 27 Jun 2020
  • Posts: 201
Reply with quote
Post Posted: Sun Jun 13, 2021 6:02 pm
Also Arduino Nano can do TTL and be powered from 5V from controller port. Straight USB. $8 free post. (Unsure if compatible, just ordered one not long ago for psx memory card reader/ writer)
  View user's profile Send private message
  • Joined: 14 Aug 2000
  • Posts: 643
  • Location: Adelaide, Australia
Reply with quote
Bit-banging and Cartridge Dumping
Post Posted: Mon Jun 14, 2021 7:52 am
I should clarify, I wasn’t blaming PuTTY as such, just stating my observations. It’s part of the PC environment as you said above.

The Arduino is a good alternative, especially if the TTL to RS232 level converters become obsolete or hard to come by. At the moment they seem to be readily available thanks to everyone trying to hack or jailbreak appliances like Set Top Boxes that run Linux. There’s also the boards that are TTL-RS232-USB all integrated in the size of the USB Plug. Pretty nifty. I’ll stick with the level converter and PuTTY for now as it’s all off-the-shelf with no extra development or support.
  View user's profile Send private message
  • Joined: 14 Aug 2000
  • Posts: 643
  • Location: Adelaide, Australia
Reply with quote
Bit-banging and Cartridge Dumping
Post Posted: Mon Jun 21, 2021 3:41 am
Micro-UPDATE:

Programmed and tested code that generates the CRC32 for game image on a cart. I decided the suggested CRC32 functionality would be good to have as it gives a readily available method to verify received dumps on the receiving PC (e.g. if you have 7zip installed, CRC32 is a right-click option). CRC32 is also the legacy thumbprint for dumped images and dumping logs of course.

I’d be keen to know if anyone else has run code on a Master System to generate CRC32 and what sort of performance you achieved?

CRC32 is murder to implement on an 8-bit CPU with an Accumulator instead of general registers and a small number of registers running at less than 4MHz. I tried a (LUT-less) computation method, then an optimized computation method (without LUT) which optimized the shift operations, before settling on a byte-wise computation with a LUT.
  View user's profile Send private message
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8405
  • Location: Paris, France
Reply with quote
Post Posted: Mon Jun 21, 2021 7:51 am
Might be interesting to add it as a compile time define to SMSDump
https://www.smspower.org/forums/12294
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13812
  • Location: London
Reply with quote
Post Posted: Mon Jun 21, 2021 10:47 am
ZEXALL has CRC32 code in it but I can’t judge its speed as it’s mixed in with the test process. It is slow, I replaced it with Adler32 once and that made it a great deal faster, but obviously being standard is nice. Code here: https://github.com/maxim-zhao/zexall-sms/blob/f41e830e2ecb37737fa49a80d572814fe5... and if we are looking to optimise it, have a look at https://github.com/maxim-zhao/z80bench which is useful for validating and benchmarking functions like this.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13812
  • Location: London
Reply with quote
Post Posted: Mon Jun 21, 2021 10:12 pm
...I got sucked into this a little bit and made a benchmarking framework for me to optimise the ZEXALL CRC32 code for the more common "checksum a range of bytes" case. I've got it down from 485 cycles per byte to 225 so far, which is somewhat indicative of what the performance would be for a ROM checksum. That is equivalent to 33s for 512KB, which is still pretty slow. It's hard to see much more scope to speed it up.

Edit: code at https://github.com/maxim-zhao/z80-crc32, see the history for the optimisation steps I've applied so far.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Aug 2000
  • Posts: 643
  • Location: Adelaide, Australia
Reply with quote
Bit-banging and Cartridge Dumping
Post Posted: Tue Jun 22, 2021 3:23 pm
I know exactly what you're talking about. There's a lot of motivation to optimise code when a task takes dozens of seconds to complete.

I haven't looked at your new version but I managed to get my implementation down to 141 CPU CLK cycles per byte. A 256KB game takes about 10.5 seconds to complete. A 512KB game would take around 21s.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13812
  • Location: London
Reply with quote
Post Posted: Tue Jun 22, 2021 4:04 pm
Hmm, 141 cycles per byte is wiping the floor with my effort... I'm curious to see the code now :)
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13812
  • Location: London
Reply with quote
Post Posted: Wed Jun 23, 2021 11:11 am
I've been nerd-sniped... I've got it down to 179 cycles per byte with code generation replacing the LUT, nowhere near 141...
  View user's profile Send private message Visit poster's website
  • Joined: 14 Aug 2000
  • Posts: 643
  • Location: Adelaide, Australia
Reply with quote
Bit-banging and Cartridge Dumping
Post Posted: Wed Jun 23, 2021 11:37 am
Very well.

This is the fastest method I came up with (by a mile) of the 3 LUT-methods and 2 LUT-less methods I wrote and trialed. The aim was to minise the byte loop ('CRC32_Loop'). There may be even faster ways out there, but I'm happy with this for now. And I've obsessed over optimizing this way too much.

;CRC32
;==============
;by asynchronous
;2021
;smspower.org
;Register usage:
;HL = pointer to block being CRC32'ed
;BC = number of bytes being CRC32'ed
;DE = pointer to CRC32 in RAM (source and result)

CRC32:         
                  PUSH AF                     ;preserve all used registers
                  PUSH BC      
                  PUSH DE      
                  PUSH HL      
                  PUSH DE                     ;convenient variable copying between registers
                  PUSH HL      
                  PUSH BC      
                  PUSH DE      
                  POP HL                     ;get the CRC32 from RAM and put it into registers BC',DE'
                  LD C,(HL)      
                  INC HL      
                  LD B,(HL)      
                  INC HL      
                  LD E,(HL)      
                  INC HL      
                  LD D,(HL)      
                  INC HL      
                  PUSH BC      
                  PUSH DE      
                  EXX      
                  POP DE      
                  POP BC      
                  EXX      
                  POP BC                     ;optimise 16-bit loop counter for speed
                  LD A,B      
                  LD B,C      
                  LD C,A      
                  POP HL      
CRC32_Loop:         
                  LD A,(HL)                  ;get the next byte to be CRC'ed
                  EXX                        ;switch to BC',DE',HL'
                  XOR C                     ;XOR the byte with the LSB of the CRC32
                  LD L,A                     ;generate the LUT ptr
                  LD H,$31                  ;MSB of LUT >> 2 NOTE! LUT base address must be on a 1KB boundary e.g. $C400
                  ADD HL,HL      
                  ADD HL,HL      
                  LD A,B                     ;XOR the LUT with the CRC >> 8
                  XOR (HL)      
                  LD C,A      
                  INC HL      
                  LD A,E      
                  XOR (HL)      
                  LD B,A      
                  INC HL      
                  LD A,D      
                  XOR (HL)      
                  LD E,A      
                  INC HL      
                  LD D,(HL)      
                  EXX                        ;switch back to BC,DE,HL            
                  INC HL                     ;increment pointer to next byte to be CRC'ed
                  DJNZ CRC32_Loop            ;and loop
                  DEC C      
                  JR NZ,CRC32_Loop
                  EXX                        ;the (almost) final CRC32 is in BC',DE'
                  POP HL                     
                  LD (HL),C
                  INC HL
                  LD (HL),B
                  INC HL
                  LD (HL),E
                  INC HL
                  LD (HL),D
                  EXX      
                  POP HL      
                  POP DE      
                  POP BC      
                  POP AF      
                  RET      

CRC32_Finalise:                                 
                  PUSH AF
                  PUSH BC
                  PUSH DE
                  LD B,4
CRC32_Finalise_Loop:
                  LD A,(DE)
                  XOR $FF
                  LD (DE),A
                  INC DE
                  DJNZ CRC32_Finalise_Loop
                  POP DE
                  POP BC
                  POP AF
                  RET
  View user's profile Send private message
  • Joined: 14 Aug 2000
  • Posts: 643
  • Location: Adelaide, Australia
Reply with quote
Bit-banging and Cartridge Dumping
Post Posted: Wed Jun 23, 2021 11:42 am
@Maxim, 179 cycles per byte with no LUT is AWESOME!
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13812
  • Location: London
Reply with quote
Post Posted: Wed Jun 23, 2021 1:46 pm
Hmm, that gives me some ideas. I’ll inject it into my test bed and do some comparisons. My LUT-less version is generating code for every LUT entry and dispatching to it, so it’s still using a LUT really.

Edit: applying some of these principles to my LUT code (mainly doing the work in the alternate register set, which I'd done for the codegen but not considered adding to the LUT yet, plus the LUT alignment which I'd managed to think wasn't possible for a 1KB table) gets down to 128 cycles per byte, mainly gaining by loop unrolling - the main loop body is almost identical. The code-gen version loses out because the cost of xoring from memory is identical to that of xoring an immediate value, and the overhead to dispatch to the generated code is greater than the benefit from skipping the xors with 0.

For comparison, 128 cycles vs. 141 cycles per byte is 18s vs. 20s over 512KB. Sadly, this optimisation is unlikely to help ZEXALL much as it repeatedly feeds the algorithm only quite small buffers.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Aug 2000
  • Posts: 643
  • Location: Adelaide, Australia
Reply with quote
Bit-banging and Cartridge Dumping
Post Posted: Tue Sep 21, 2021 2:35 am
Small update:

The dump screen graphics and animation are complete.

The project has been on a hiatus for a few months due to my work getting hectic and other electronics projects needing overdue attention. But development will be re-starting pretty soon.
  View user's profile Send private message
  • Joined: 27 Jun 2020
  • Posts: 201
Reply with quote
Post Posted: Tue Sep 21, 2021 5:39 am
Photos??
  View user's profile Send private message
  • Joined: 12 Apr 2005
  • Posts: 386
  • Location: London, United Kingdom
Reply with quote
Post Posted: Wed Sep 22, 2021 3:13 am
Very interesting work!

I've been using a controller port as a serial interface too, though I can see my pinout doesn't match NeonMan's. Unfortunately as I need to use both outputs (TxD and RTS) I won't be able to make mine compatible, but to avoid future confusion I wonder what pinout you're using? Mine's as follows:

; TxD = 7 Port B TH ($3F.7)
; RxD = 2 Port B Down ($DC.7)
; RTS = 9 Port B TR ($3F.6)
; CTS = 1 Port B Up ($DC.6)

Using the most significant bit as the data bits makes them easy to shift in and out, and I'm using a very similar pinout for loading from cassette:

; MIC-> = 7 Port B TH ($3F.7)
; <-EAR = 2 Port B Down ($DC.7)
; MOTOR = 9 Port B TR ($3F.6)
; PHASE = 1 Port B Up ($DC.6)

If we can avoid having to make subtly different cables for every different project, so much the better...
  View user's profile Send private message Visit poster's website
  • Joined: 25 Jul 2007
  • Posts: 639
  • Location: Melbourne, Australia
Reply with quote
Post Posted: Wed Sep 22, 2021 10:50 am
Another option would be to follow the pinout used on the Game Gear when using the G2G to DB9 adapter

TxD = 6
RxD = 9


You could also use pin 7 as RTS as it has a hardware interrupt tied to this pin.

Leaving 1-4 available for the CTS line.

You can see details here, I can tell you the mapping from G2G cable to the DB9 connector is 1 to 1 (eg 1 = 1, 2 = 2 etc).

https://www.smspower.org/Development/GearToGearCable
  View user's profile Send private message
  • Joined: 14 Aug 2000
  • Posts: 643
  • Location: Adelaide, Australia
Reply with quote
Bit-banging and Cartridge Dumping
Post Posted: Wed Sep 22, 2021 11:50 am
I'm using the controller port as output only, no hardware flow control, and configurable to use either or both of the output lines on either or both of the controller ports.


@L10N37 no early reveal photos. You're just gonna have to wait until UAT.
  View user's profile Send private message
  • Joined: 12 Apr 2005
  • Posts: 386
  • Location: London, United Kingdom
Reply with quote
Post Posted: Wed Sep 22, 2021 1:30 pm
djbass wrote
Another option would be to follow the pinout used on the Game Gear when using the G2G to DB9 adapter

TxD = 6
RxD = 9

I'm not sure that would work as TxD needs to be an output so would need to be connected to TH (7) or TR (9) on the Master System, unless I've missed something there? I picked TH for TxD and "down" for RxD as both are the most significant bits when reading/writing the ports so can be more easily manipulated.

asynchronous wrote
I'm using the controller port as output only, no hardware flow control, and configurable to use either or both of the output lines on either or both of the controller ports.

Very nice, I suppose that makes life much easier for the user. :)
  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!