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 - Sega Graphic Board v2.0 reverse engineering

Reply to topic Goto page 1, 2  Next
Author Message
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8644
  • Location: Paris, France
Reply with quote
Sega Graphic Board v2.0 reverse engineering
Post Posted: Wed Oct 01, 2014 12:00 pm
Last edited by Bock on Tue Oct 07, 2014 6:50 pm; edited 2 times in total
Thread for reverse engineering the hardware for the prototype Sega Graphic Board discussed at

http://www.smspower.org/forums/viewtopic.php?t=15000
http://www.smspower.org/forums/viewtopic.php?t=15039

Attached a basic uncommented disassembly.
Basic disassembly.zip (18.65 KB)

  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8644
  • Location: Paris, France
Reply with quote
Post Posted: Wed Oct 01, 2014 12:16 pm
Last edited by Bock on Sat Oct 04, 2014 9:31 pm; edited 1 time in total
Bits that Maxim found out
The drawing board seems to be attached to control port 1, returning data over the low 4 bits.

If TL is low, the board has data. Pull TR low to initiate. Each transition on TH gives a new 4 bits, read as 4 bits (buttons?) then three bytes (x, y, ?), totally 7×4 bits. Raise TR and TH when done.

If TL is high, only the first 4 bits are read.

On startup, the low 4 bits are held low, then raise as a button gets pressed. That gets you past the splash screen.

[..] Commented code attached.
  View user's profile Send private message Visit poster's website
  • Joined: 13 Mar 2007
  • Posts: 51
  • Location: Portugal
Reply with quote
Post Posted: Wed Oct 01, 2014 12:32 pm
The order of the three bytes seems to be unknown/pressure, absolute X position, absolute Y position.

The absolute X and Y positions are only read if the unknown/pressure byte contains the value FD, FE, or FF. This might be some pressure detection value to indicate that the pen has been placed on the board?
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14683
  • Location: London
Reply with quote
Post Posted: Wed Oct 01, 2014 1:40 pm
I have more disassembly changes on my laptop waiting to be shared. I'll try to get it into SVN later today.

We should pull out the reading code into some homebrew that shows the raw data on-screen. That will give us a feel for the noisiness, let us see what the fourth button bit reads, and see how often the board lowers TL (I guess whenever the pen is touching the screen).
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14683
  • Location: London
Reply with quote
Post Posted: Wed Oct 01, 2014 6:25 pm
Stuff is in SVN now.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8644
  • Location: Paris, France
Reply with quote
Post Posted: Wed Oct 01, 2014 6:41 pm
Getting there with MEKA..

  View user's profile Send private message Visit poster's website
  • Joined: 13 Mar 2007
  • Posts: 51
  • Location: Portugal
Reply with quote
Post Posted: Wed Oct 01, 2014 7:21 pm
Nice,

I did a bit more checking for the first full byte read. It really looks like a simple pen-on-board check. The value read from the graphic board is stored in ram but it is never read.
  View user's profile Send private message
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8644
  • Location: Paris, France
Reply with quote
Post Posted: Wed Oct 01, 2014 9:28 pm
Last edited by Bock on Wed Oct 01, 2014 9:33 pm; edited 2 times in total
That's the code in MEKA:

Storage
struct t_peripheral_graphic_board_v2
{
   u8 unknown;      // Possibly pressure?  Software wants. 0xFD-0xFF
   u8 buttons;       // 3-bit - 0: released 1: pressed
   u8 x, y;             // pen position
   u8 read_index; // internal counter
};


Port 3F write
   // Graphic Board v2.0
   if (Inputs.Peripheral[0] == INPUT_GRAPHICBOARD_V2)
   {
      if ((old_value ^ new_value)   & 0x20)
         Inputs.GraphicBoardV2[0].read_index++;
      if (new_value & 0x10)
         Inputs.GraphicBoardV2[0].read_index = 0;
   }


Port DC read
      v &= 0xF0;
      if (tsms.Port3F & 0x10)
      {
         v &= ~0x1F;
      }
      else
      {
         switch (p->read_index & 7)
         {
         case 0: v &= ~0x10; v |= p->buttons ^ 0x0f; break; //board always ready
         case 1: v |= p->unknown >> 4; break;
         case 2: v |= p->unknown & 0x0f; break;
         case 3: v |= p->x >> 4; break;
         case 4: v |= p->x & 0x0f; break;
         case 5: v |= p->y >> 4; break;
         case 6: v |= p->y & 0x0f; break;
         }
      }


Transform mouse position
   t_peripheral_graphic_board_v2* p = &Inputs.GraphicBoardV2[player];

   y += 32;
   y += 4;
   x -= 4;

   if (x <0> 255) x = 255;
   p->x = (u8)x;

   if (y <0> 255) y = 255;
   p->y = (u8)y;
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8644
  • Location: Paris, France
Reply with quote
Post Posted: Wed Oct 01, 2014 9:29 pm
I am ready-ish to release it would be nice if one or two other emulators would be ready to release and then we can schedule the ROM release for in a few days.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14683
  • Location: London
Reply with quote
Post Posted: Wed Oct 01, 2014 10:02 pm
HTML sanitisation broke the last bit of code.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Apr 2013
  • Posts: 623
Reply with quote
Post Posted: Wed Oct 01, 2014 10:11 pm
Bock wrote
I am ready-ish to release it would be nice if one or two other emulators would be ready to release and then we can schedule the ROM release for in a few days.

I am kinda ready as well :)

  View user's profile Send private message Visit poster's website
  • Joined: 13 Mar 2007
  • Posts: 51
  • Location: Portugal
Reply with quote
Post Posted: Thu Oct 02, 2014 6:46 am
Mess is ready as well, I'd just have to commit the code I shared earlier.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14683
  • Location: London
Reply with quote
Post Posted: Thu Oct 02, 2014 8:23 am
Timings used by the game:

Read TL   
(10us)  Lower TR   66us  Read bits (Buttons)
354us   Lower TH  149us  Read bits (Pressure high)
(13us)  Raise TH  149us  Read bits (Pressure low)
 57us   Lower TH  149us  Read bits (X high)
(13us)  Raise TH  149us  Read bits (X low)
 64us   Lower TH  149us  Read bits (Y high)
(13us)  Raise TH  149us  Read bits (Y low)
(12us)  Raise TR (done)

Brackets indicate sections with no delay code. There's a consistent 149us (533 cycles) between the TH signal and reading the new nibble, no real delay between nibbles of the same byte, ~60us when switching bytes, and a weird 354us pause between reading the buttons and signalling TH for the first pen data nibble.

My supposition is this: TL signals that the three bytes are available, so it is presumably a "pen down" signal. However, the values aren't already cached in memory anywhere. The first non-button read triggers a slow operation to get the precise values, which are then in some kind of buffer. Switching nibble is a superfast operation, but moving to the next byte is a more costly buffer shift. This is all informed by no hardware expertise at all :)
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8644
  • Location: Paris, France
Reply with quote
Post Posted: Thu Oct 02, 2014 9:15 am
Calindro: your buttons switches are inverted. Se how the 3 menu items are red in yours, compare to the photo in the other thread of the graphic board running on real hardware.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Apr 2013
  • Posts: 623
Reply with quote
Post Posted: Thu Oct 02, 2014 9:57 am
Bock wrote
Calindro: your buttons switches are inverted. Se how the 3 menu items are red in yours, compare to the photo in the other thread of the graphic board running on real hardware.

Oh wow thanks for carefully checking! I might not have noticed it in near future.
Do I need to hold down the pen button while drawing with the pen in order to actually draw pixels to the screen? Or is there something else I'm doing wrong now?
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8644
  • Location: Paris, France
Reply with quote
Post Posted: Thu Oct 02, 2014 10:16 am
Yes you need to hold the button.
The interface mapping is quite confusing frankly, I mapped it to 3-button mouses on MEKA but it's still confusing. Not sure what's best.

Additionally I have tried the real hardware and similarly to the Terebi Oekaki it is quite hard to press at times. I wonder if with time or usage it degrade and maybe lowering the 0xFD threshold in the software but it make it works better with real hardware.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Apr 2013
  • Posts: 623
Reply with quote
Post Posted: Thu Oct 02, 2014 10:38 am
Ok then I got it fixed now, thanks! :)
Do you set pressure and press the pen button both on left mouse button? Or do you have them seperated?
  View user's profile Send private message Visit poster's website
  • Joined: 13 Mar 2007
  • Posts: 51
  • Location: Portugal
Reply with quote
Post Posted: Thu Oct 02, 2014 11:55 am
I simply always set pressure, that keeps it easy to use for end users.
  View user's profile Send private message
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8644
  • Location: Paris, France
Reply with quote
Post Posted: Thu Oct 02, 2014 11:58 am
I also always set pressure I thought it made sense for mouse inputs.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Apr 2013
  • Posts: 623
Reply with quote
Post Posted: Thu Oct 02, 2014 12:09 pm
But that way I'm always getting a line from the color select to the first point I click on.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8644
  • Location: Paris, France
Reply with quote
Post Posted: Thu Oct 02, 2014 12:14 pm
I don't understand - if the Pen button isn't pressed there's no drawing happening, it works for me. Setting "pressure" all the time makes the cursor follow user's mouse but doesn't draw extra. If you hold the mouse on a "color" button at the top it and press Pen it change the Pen color without drawing extra.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Apr 2013
  • Posts: 623
Reply with quote
Post Posted: Thu Oct 02, 2014 12:17 pm
Yeah, sorry I just noticed right after I had posted. Now it works as expected :)
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8644
  • Location: Paris, France
Reply with quote
Screenshots
Post Posted: Fri Oct 03, 2014 8:31 am
Posting some screenshots - if you have more (in native resolution) it would be helpful.
test-07.png (3.71 KB)
test-07.png
test-09.png (3.82 KB)
test-09.png
test-10.png (4.25 KB)
test-10.png

  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8644
  • Location: Paris, France
Reply with quote
Post Posted: Fri Oct 03, 2014 9:22 pm
I'll release the ROM tomorrow around 8 pm GMT
Feel free to release your emulator earlier if you want.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14683
  • Location: London
Reply with quote
Post Posted: Sat Oct 04, 2014 12:37 pm
Are we going to have a competition as we did for Terebi Oekaki? This software seems much more advanced, and less limited, so real art is almost achievable :)
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8644
  • Location: Paris, France
Reply with quote
Post Posted: Sat Oct 04, 2014 9:21 pm
Yes we should!
Attached the latest disassembly by Maxim.

  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8644
  • Location: Paris, France
Reply with quote
Post Posted: Sat Oct 04, 2014 9:53 pm
The dump is now released
http://www.smspower.org/forums/viewtopic.php?t=15039
http://www.smspower.org/Games/SegaGraphicBoard-SMS
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14683
  • Location: London
Reply with quote
Post Posted: Sun Oct 05, 2014 1:22 pm
Did you test the values returned on the real device yet? It would be good to find what ranges of values are there, and also whether TL is a pen down signal. Also to find what you read when TL is high - last seen values perhaps?

Given the fairly simple protocol, can anyone comment on the difficulty of making a hardware reproduction? I'm thinking touchscreen, buttons and microcontroller? How expensive might it be?
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8644
  • Location: Paris, France
Reply with quote
Post Posted: Sun Oct 05, 2014 3:20 pm
Didn't run any test on the real hardware sorry. If a test ROM is made I'm happy to run it but I probably won't have time to make one.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14683
  • Location: London
Reply with quote
Post Posted: Tue Oct 07, 2014 9:59 am
I've moved the disassembly from SVN to GitHub:

https://github.com/maxim-zhao/smsgraphicboard

I'm only sporadically syncing from my local changes so there's probably more than what you see. I'm suspicious that the second 16KB is probably full of code too...
  View user's profile Send private message Visit poster's website
  • Joined: 14 Apr 2013
  • Posts: 623
Reply with quote
Post Posted: Tue Oct 07, 2014 10:13 am
Maxim wrote
I've moved the disassembly from SVN to GitHub:

https://github.com/maxim-zhao/smsgraphicboard

I'm only sporadically syncing from my local changes so there's probably more than what you see. I'm suspicious that the second 16KB is probably full of code too...

Starting from $46d9 the bank is filled with $ff except for the TMR SMS header and the data before that is tile data. There's only unused code that is being shown as data. All the used code got identified statically.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14683
  • Location: London
Reply with quote
Post Posted: Tue Oct 07, 2014 1:03 pm
I hadn't actually checked :)
  View user's profile Send private message Visit poster's website
  • Joined: 16 Jan 2008
  • Posts: 4
  • Location: South of the Mason-Dixon Line
Reply with quote
Post Posted: Thu Oct 09, 2014 2:40 am
Many thanks for obtaining such an awesome piece of history and documenting/releasing it!

I added support to CrabEmu for it. :)
crabemu-20141008.png (42.89 KB)
crabemu-20141008.png

  View user's profile Send private message Visit poster's website
  • Joined: 29 Oct 2014
  • Posts: 89
  • Location: Chicagoland, USA
Reply with quote
Post Posted: Thu Dec 11, 2014 8:35 pm
Maxim wrote
Given the fairly simple protocol, can anyone comment on the difficulty of making a hardware reproduction? I'm thinking touchscreen, buttons and microcontroller? How expensive might it be?

I was just thinking about this. Yeah, it would be cheap. It looks to be a resistive digitizer connected to a microcontroller with ADCs and the ability to respond quickly enough on the data bus.
Something along the lines of this digitizer could be used: http://www.ebay.com/itm/7-0-7-inch-4-Wire-Resistive-Touch-Panel-Screen-Free-ZIF-...
They're commonly used in cheapo 7 inch Android tablets. Probably an ATTiny48 could handle all of this without breaking a sweat. I have some 7 inch digitizers sitting around, and some ATTiny48s... maybe I'll have a go at this, based on the documentation here, and see if it works well on my SMS...
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14683
  • Location: London
Reply with quote
Post Posted: Thu Dec 11, 2014 9:41 pm
I thought you usually have to calibrate resistive digitisers, is that avoidable? Or does it only matter when you are overlaying a screen?
  View user's profile Send private message Visit poster's website
  • Joined: 29 Oct 2014
  • Posts: 89
  • Location: Chicagoland, USA
Reply with quote
Post Posted: Thu Dec 11, 2014 9:53 pm
In my experience, the calibration is relatively close for touchscreens of the same make and model. The ATTiny48 (and most other AVRs) has some EEPROM for storing things like calibration values, so that isn't a deal breaker. Could just plug it in and hold the buttons in some configuration as it receives power to put it in calibration mode. Make a little overlay that can be printed out at a certain size to show the calibration points, stick that over the screen, and you're all set. ;)
I'm quite sure a decent bezel could be easily and cheaply made with 3D printing, if there isn't some off-the-shelf solution.
  View user's profile Send private message
  • Joined: 29 Oct 2014
  • Posts: 89
  • Location: Chicagoland, USA
Reply with quote
Post Posted: Fri Dec 12, 2014 1:39 pm
Found this touch panel, which I am happy with for two reasons:
1) They give dimensions and a pinout for
2) It seems to be cheaper with the ZIF connector than anything I could find on eBay
It's also happy with 5V, which is good, because that's what the whole circuit runs on ;) So there's a lot to like about it.

I've laid out a small PCB (well under 50x50mm, so cheaply made by any number of PCB houses). Now, to verify my understanding, there are only 3 buttons on the device, correct? There's not a fourth hiding somewhere? It seems like it can carry 4 buttons' worth across the data pins of the controller port. Would it make sense to include a fourth for homebrew, even if the original doesn't have it? Can leave it unpopulated if you don't want it.

Also, I'm thinking of having an LED that lights up when the unit is in calibration mode. Are there other LEDs that are on the original hardware that might be useful?
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14683
  • Location: London
Reply with quote
Post Posted: Fri Dec 12, 2014 3:38 pm
Last edited by Maxim on Fri Dec 12, 2014 4:16 pm; edited 1 time in total
The graphics board software reads three buttons, but you could put six in there (I think). It also reads what looks like a pressure value, but hardly uses it and you could fake it.

There's no LEDs on the board, you could light an LED when the digitiser is being accessed by the software as a feedback mechanism.
  View user's profile Send private message Visit poster's website
  • Joined: 29 Oct 2014
  • Posts: 89
  • Location: Chicagoland, USA
Reply with quote
Post Posted: Fri Dec 12, 2014 3:57 pm
Hmmm? Now I'm confused... how would you be able to read 6 buttons? If TL/TR/TH are used as control signals (such as pen down, start of read, and next nybble), and only the first nybble represents buttons, wouldn't that be a max of 4? Please explain :) I can wire up as many buttons as we want, really, but the more I wire up, the closer they'll be on the PCB.

I was planning on measuring the pressure and if I get a half-way decent measurement out of the ADCs, I'd return 0xFD or higher (based on the MEKA code posted by Bock). I think I can implement a touch sense interrupt as well, where it fires off a measurement as soon as it senses that the pen is down.

As a side note, I'm thinking that these can be made in multiple sizes as well. The PCB is small, so I'd think one could keep the same PCB on all of them, but I've used a number of resistive touch panels of varying sizes, and I think with modern ones and good ADCs, even some of the small ones may provide a sufficiently good experience.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14683
  • Location: London
Reply with quote
Post Posted: Fri Dec 12, 2014 4:21 pm
I was thinking the software configured the buttons as inputs when it read from the port, but it doesn't, so that only leaves the four D-pad bits as you mentioned. You could chain any number of extra 4-bit phases onto the protocol for extra buttons if you wanted, and remain compatible with the software. However, I don't think it's worth the effort.
  View user's profile Send private message Visit poster's website
  • Joined: 29 Oct 2014
  • Posts: 89
  • Location: Chicagoland, USA
Reply with quote
Post Posted: Fri Dec 12, 2014 4:26 pm
That's true, extra buttons could be read after the touch info, but probably doesn't add too much. So, 4 buttons sound good then?
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14683
  • Location: London
Reply with quote
Post Posted: Fri Dec 12, 2014 5:25 pm
Yes, why not.
  View user's profile Send private message Visit poster's website
  • Joined: 29 Oct 2014
  • Posts: 89
  • Location: Chicagoland, USA
Reply with quote
Post Posted: Mon Dec 15, 2014 12:03 pm
OK, PCBs are sent to the board house... I decided to not go overly fancy with this. I've got two PCBs: the main one, and the one that goes to the buttons on the side with a small cable (or half a dozen wires). For space reasons, I left off the LEDs, because they'd make the bezel larger by including them, the way I have it laid out. (I figure at this point, it's worth getting the PCBs and finding out what works well and doesn't work well, and refine the design later.) Should see the boards come in early January. My plan is to make a small calibration jig by connecting a special DB9 socket on the end of it, which puts it into calibration mode. Then that design can have LEDs and things on it, without putting them on the device itself, keeping it nice and compact. That bit can be hand-soldered on protoboard by anyone who's interested in calibrating them. (As I understand it, the calibration shouldn't change over time, so it's probably reasonable.)

In the meantime, I'm going to order a few different touch panels and we can see what size makes sense. Can anyone tell me the dimensions of the touch panel (in the bezel) of the original one? Ideally we'd stick with something close to that by default.

It looks (from pictures, and sizes that I found on the Sega Daihyakka and other sources) like the Terebi Oekaki Graphics Board had a 5" 4:3 panel in it. That might be difficult, because there aren't many made in the 4:3 aspect ratio anymore in that size, and if I get a 7" 16:9 to approximate it, the bezel size is going to balloon quite a bit. There's a 5.7" 4:3 one I found, but the price is higher than any of the other options. Still might be worth it though for the closeness in size it offers.

I've designed the button panel to break or be cut in half and still offer 4 buttons (it's laid out for 8, and in a large 4 button unit, only half of them are populated, but well spaced apart). I don't know how large the button area should be in terms of comfort, so I figure this way I have a bit of play on that. I might decide that neither are ideal and whip out the protoboard for that part also, but it fit in another PCB design I wanted to get made, so that worked out well.

Once I have something usable (may be awhile), we can figure out how to get the finished ones in people's hands. I should have roughly 10 PCBs to start with, but I imagine that once I build a few of these, I might find things that I'm not so fond of, so it may be that these won't see the light of day, in favor of another design.

EDIT: Ordered some touch panels in various sizes as well to play with. :)

EDIT #2: PCBs were made and are being shipped over from HK. Probably will have them in hand around New Years'. Then I'll wire them up and hopefully can make this work ;)
  View user's profile Send private message
  • Joined: 29 Oct 2014
  • Posts: 89
  • Location: Chicagoland, USA
Reply with quote
Post Posted: Fri Dec 26, 2014 8:25 pm
Got the touch panels. I haven't really taken a good hard look at them yet, but they seem to all be here and be in good shape, so those are good things...
PCBs aren't here yet. Probably another week or so on those.
  View user's profile Send private message
  • Joined: 29 Oct 2014
  • Posts: 89
  • Location: Chicagoland, USA
Reply with quote
Post Posted: Mon Jan 05, 2015 5:04 pm
Don't know if anyone's actually following this, but the PCBs are here. Need to cut them apart from some other projects' PCBs (I bought a larger panel and need to cut them apart by hand), but they look very nice. I'm quite happy with them.
The button panel has 8 buttons on it but also has three locations for where to connect a ribbon cable across the two boards. One (the one in the middle) connects to every other button on the 8 button panel, so that you have a wider spacing between buttons. The other two connect to sets of 4 buttons on each side, so that the PCBs can be cut in half for a Graphics Board Mini if someone wanted one.
SMS_Graphics_Board_MainBoard_Top.jpg (141.3 KB)
Top of main PCB of Graphics Board v2.0 repro
SMS_Graphics_Board_MainBoard_Top.jpg
SMS_Graphics_Board_MainBoard_Bottom.jpg (125.55 KB)
Bottom of main PCB of Graphics Board v2.0 repro
SMS_Graphics_Board_MainBoard_Bottom.jpg
SMS_Graphics_Board_BtnPanel_Top.jpg (307.09 KB)
Top of button panel PCB of Graphics Board v2.0 repro
SMS_Graphics_Board_BtnPanel_Top.jpg

  View user's profile Send private message
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8644
  • Location: Paris, France
Reply with quote
Post Posted: Mon Jan 05, 2015 6:42 pm
Excellent. Let me know if I can be of any help with testing things on the original board too. This is a superb project by the way!
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14683
  • Location: London
Reply with quote
Post Posted: Mon Jan 05, 2015 7:12 pm
I need to pull my finger out and write a tester for the graphic board...
  View user's profile Send private message Visit poster's website
  • Joined: 17 Sep 2013
  • Posts: 140
  • Location: TC, MI
Reply with quote
Post Posted: Mon Jan 05, 2015 11:53 pm
The stop mask and silk screens seem sketchy. Who made your boards?
  View user's profile Send private message Visit poster's website
  • Joined: 29 Oct 2014
  • Posts: 89
  • Location: Chicagoland, USA
Reply with quote
Post Posted: Tue Jan 06, 2015 2:04 am
I'm not sure what part of it you're reacting to... some of those things may also be related to how I panelized my designs (poorly, because they're all quick prototype runs). The solder mask looks pretty dead on to me. The silkscreen does indeed seem to be a little bit offset, but that doesn't bother me all that much, and could also be a mistake in my Gerber files.
They were made by DirtyPCBs.
  View user's profile Send private message
  • Joined: 29 Oct 2014
  • Posts: 89
  • Location: Chicagoland, USA
Reply with quote
Post Posted: Wed Jan 07, 2015 12:48 pm
Okay, starting to get into the nitty gritty here (writing some firmware for this thing), and I've got a few questions.

1) Does the Graphics Board software care if I write the button values to D0-D3 always (i.e. before it pulls TR low)?

Explanation of 1) It's far easier for me to just poll the buttons every few milliseconds and write it out to the data pins blindly, regardless of the state of TR. Because the buttons are the first things to be read in any situation, and we know that the software won't start toggling TH until we pull TL low, I figure I can basically ignore TR most of the time (I'll just verify that it's low when I see TH toggling to increment the value pointer going out.) I suspect that TR is just to wake up the hardware in the Graphics Board, but the ATTiny48 I'm using is so low-power (around 5mA max, except for the draw from inputs/outputs) that I don't know that we care enough to put it to sleep.

2) "There's a consistent 149us (533 cycles) between the TH signal and reading the new nibble, no real delay between nibbles of the same byte, ~60us when switching bytes"
Does this mean that I have 149us to send the next nybble (and make sure that the data lines are driven stable)?

Explanation of 2) My plan is to read the touchscreen data and reorder the nybbles to look like the SMS output before I pull TL low. Once I see TR go low, then I start polling TH constantly and if I see that it changes, then I shift out the next nybble onto D0-D3. My code is going to be in C to begin with, and only going to resort to AVR ASM if I have to, but I've got an 8MHz microcontroller here, so it's probably not going to be necessary. I've got TL and D0-D3 on the same port, so all my outputs are controlled simultaneously, which, in this case, really doesn't matter all that much.

3) When does TL go high again? Do we know? Do we care, once the touchscreen data is being read out? Should I set it high again immediately after TR goes high again, or sooner than that?
  View user's profile Send private message
Reply to topic Goto page 1, 2  Next



Back to the top of this page

Back to SMS Power!