Forums

1. No, it actually expects that I think. The board detection consists of reading the board and checking for no buttons pressed (giving 0 in the low four bits, impossible for other controllers), and the title screen then polls for a button press, never changing TH.

2. Yes, that's the time from the TH output to the next read. There's a little margin for error as I'm assuming consistent timings on the hardware side from the software instructions. Also, a PAL system has a slightly faster clock which means less time.

3. I think the board sets TL whenever it has pen values to transmit. This might be a direct "pen down" signal or it might be set only after the pen data is latched and ready to send.

Maxim wrote

1. No, it actually expects that I think. The board detection consists of reading the board and checking for no buttons pressed (giving 0 in the low four bits, impossible for other controllers), and the title screen then polls for a button press, never changing TH.

OK, good. Just to verify, all zeroes would be all buttons pressed, right? Then when a button is pressed, then they all go high (except for the pressed button)?

Maxim wrote

2. Yes, that's the time from the TH output to the next read. There's a little margin for error as I'm assuming consistent timings on the hardware side from the software instructions. Also, a PAL system has a slightly faster clock which means less time.

I suspect that the code won't need much time to operate (it's just reading the port, ANDing out the other bits, XORing it with what I previously saw TH to be, and if non-zero, put the next nybble on the data lines, and then gets ready for the next difference in TH). On an 8MHz micro, even if the while-statement is 20 cycles to evaluate and jump as needed, we're still in the realm of a few microseconds, so probably going to be fine here if we're talking ~150us (even if it's 20% faster on PAL machines or something... shouldn't be an issue)

Maxim wrote

3. I think the board sets TL whenever it has pen values to transmit. This might be a direct "pen down" signal or it might be set only after the pen data is latched and ready to send.

OK. I'm going to have to simulate this anyway, as the microcontroller I use doesn't have a dedicated touchscreen controller (and we don't need one -- it just makes touchscreen use a little easier). So I'll only set TL low after I've got the X/Y coords in the format that the software is going to ask (and I've detected a touch from the pen, of course).

In any case, this is going pretty smoothly so far... I made a version of the firmware that's just missing the touchscreen code itself (everything else is implemented), and I'm using a whole 4% of flash and 3% of data storage. I think this micro will likely suffice ;)

No, the buttons are active high logic. Bit 3 has to be zero to get past the title screen, bits 2 to 0 are the buttons and it wants them to go from all zero to at least one non zero.

Note also that it reads the buttons and pen down signal both before and after lowering TR. Only after the first TH clock after lowering TR should it emit anything else.

Ah, OK... they aren't active high on any other controller, are they? I can invert my logic though, no problem. Actually, that makes the logic easier. (I expected it was outputting zeroes until the board saw buttons, and then it'd switch to all high except one and go into active low logic. My mistake!)
Made that change by inverting the button signals coming in with an XOR before I do anything else with them. (I don't care at all what the button values are -- the board itself wouldn't do anything with them.)

I switch back to updating buttons + pen down after TR goes high, so that's fine.

I've put the initial code and schematic up on GitHub for people to look over if interested.
https://github.com/ishiyakazuo/SMSGraphicsBoard
That way, if I were to die tomorrow (and given the weather in Chicago lately, that's not an impossibility), this work shall not be lost. :)

I think every other controller uses active low, except when transmitting digital values (e.g. paddle position) when the data seems to be uninverted (although if the axis was reversed and the bits inverted, it would look the same).

In theory, you could move a paddle to the exact 0 position and fool the board detection, likewise with the sports pad. The light phaser leaves the relevant pins unconnected so they are pulled high. On a control pad, it's impossible to press up, down, left and right at the same time.

Why'd you have to go and mention the paddle... now I'm thinking about "how can I add a paddle to this thing" :P (Probably would be pretty crappy to hold though with the touch panel on there, but again, not too difficult of a hardware design to duplicate.)
Wonder if anyone would be interested in a paddle controller that has a switch that switches between Japanese mode and Export mode: Paddle Control v2.0.

Since the paddle has stops at either side, a touch panel emulating it from one axis would be a reasonable approximation (it'd be good for Megumi Rescue). Less so for Out Run, where you really want rotation I think. (Interpreting circular motions on the panel would be tough as well.) Better to make it its own project, maybe after this one...

Although I did consider the possibility of using the touch panel for it, I was really meaning to say that I was thinking about how I could put a rotary encoder or potentiometer somewhere on this thing ;)

Once this is done, a lot of the code could probably be reused for the Paddle if a potentiometer is used.

In other news, is anyone interested in helping with 3D modeling of cases for the Graphics Board? I can provide measurements as needed for the various pieces, but I'm pretty worthless on that side of things.

I added some attempted timing diagrams here:

https://github.com/maxim-zhao/smsgraphicboard/blob/master/Dasm/graphicboard.asm

Cool, thanks.
I'm hoping to get my PCBs cut apart this weekend, once it's a balmy -6C outside (much better than the -22C it was this morning). Then I'll solder up the prototype, try programming it... maybe get a repro cart of the software wired up... yeah, this'll probably still take me a good week or so.

I'm getting quite far in my disassembly now and it's shown that emulating the pen as always down stops you from achieving certain things. In particular I think you can touch the screen, hold PEN to start drawing, lift the pen, then touch elsewhere to draw a line. It also allows you to operate menus without losing your last drawing position (provided you lift the pen), although I don't really see how that is useful.

In operation, I don't see a meaningful difference between PEN and DO. I think there is never a time when you can use both.

There are vestiges of 32KB of on cartridge RAM (mapped via the usual Sega mapper in slots 2-3), which it blanks on startup but then never touches again. Maybe at one time they hoped to operate on a bitmap in RAM and then render to the screen later? That would have allowed for a larger canvas, but you couldn't view it all at once. It might also have helped with the speed, although not by much.

There isn't much that can obviously be done to improve the speed. It mostly works in pixel plotting mode, reading four bytes from VRAM to RAM (one row of a tile) and then modifying the relevant bit in each bitplane. That gets pretty slow in the fattest pen mode, where each point consists of nine pixels, especially as it then overwrites many of them. Maybe some tailored algorithms for drawing thick lines would help there.

Since drawing is so slow, it reads and writes VRAM during the active display. It does this because it can get more work done overall this way, and also because it can remain responsive to certain things managed in the VBlank (mostly pen and sprite updates) while drawing. It doesn't let you interrupt the action in progress, though.

This makes pixel plotting the main speed cost, so the algorithms themselves probably don't matter much, apart from when they can avoid pixel plotting entirely. For example, "square" filling optimises where it is setting all 8 pixels of a tile row. Circle filling doesn't because that's rather harder to know when you can.

Lots of interesting info there :)
I've been fairly quiet on this for a few reasons... the largest of which was, I didn't have a way to test this. I don't have a large SMS cart collection, so taking one of my cartridges and replacing the ROM was out of the question. I went ahead and laid out my own 32KB ROM PCB. I'm hoping to get one soldered up next week (while I have the PCBs in hand, this weekend is already pretty fully booked).
I did find one or two mistakes on the rev. A PCB. While they weren't deal-breakers, the analog measurement circuit wasn't as pristine as I'd like, so I added an inductor to help clean the reference voltage further. I also realized that I forgot the side solder pads to help hold the touchscreen connector down, which isn't a huge deal (could just tape the ribbon cable down to the PCB to avoid it wiggling too much), but I thought I'd like to do a little better. So I just got the rev. B PCBs, and while they have the pads, they're masked over! Oops! Nothing a little scraping by hand won't fix, but still... rev. C will likely be the one I end up being happy with. ;)
My boss happened to discuss with me a particular problem that we were having, and it turns out that the circuit used for this is fairly close to the circuit needed to test something there, so I made some small modifications to accommodate that need as well. (On the plus side, that means I can play with this at the office somewhat in my spare time. Unfortunately, spare time has become a rare commodity!)

Isn't onboard 32KB just a vestige of the possibility of saving your drawing on the cartridge?

Maybe (I can think of more possibilities). The fact that it blanks it makes me think it's not persisted, though.

Unless the blanking was done in a fit of rage when that feature was removed, like pouring salt on the land ;)
But I think your initial explanation is probably more plausible.

My disassembly is now complete, except for some tidying up and coming back to some questions. All RAM is accounted for, graphics are pulled out to PNGs, there's lots of enumerations for avoiding magic numbers in there.

https://github.com/maxim-zhao/smsgraphicboard/tree/master/Dasm

Some of the code seems to be pretty well optimised (rectangle filling), some seems pretty sub optimal (drawing thick lines, filled circles... most parts, actually). It might be relatively easy to add a line drawing feature (beyond the pen point interpolation I mentioned above, letting you define the start and end points on-screen). Undo is not going to happen. Loading and saving to SRAM is definitely possible (you could fit two into 32KB, or maybe try compression to fit more). I'll probably never do any of this stuff... but it might be fun for someone else when the repro hardware exists.

Hi there,
Just to give an update on this -- I haven't forgotten about it, but as I alluded to a bit in my previous post, I've become super busy at work, and when I get home, I don't really much feel like working on code/electronics. On the plus side, I think there's light at the end of the tunnel on the work side of things (my project is nearing completion), and the similar project I had to do for work is complete now, so I think once I get back to this, it shouldn't take very long to get it done.
Anyway, I had mentioned the possibility of making your own paddle controller with a similar circuit, but someone has beaten me to it:
http://www.raphnet.net/electronique/sms_paddle/index_en.php
Thought that might be interesting for some to see.

Hey,
I may have to pack the board in storage in France (currently cleaning up our London place for travelling for a few months). While it is by my side, is there any test I could perform to help testing the HW ?

Hey guys,
Omar and me have done a lot of testing and basically we could confirm everything that has been concluded before:
Initially the data pins are low, TR and TH are high.
After lowering TR you can read the buttons (state 0) from the data pins.
When an edge on TH is detected and the state number is less than 6 the state number gets increased.
The following values can be read from the data pins in the given state:
0 : buttons
1 : pressure high
2 : pressure low
3 : x high
4 : x low
5 : y high
6 : y low

Pulling TR up resets the state counter to 0. The reset takes some time. So right after pulling TR up the value for the current state can still be read from the data pins.

When the pen (a finger works as well) touches the board TL is pulled low and pressure is set to $fd (most of the times).
When applying some force the value for pressure can also reach $fe. At the top left corner Omar could also get $fc for pressure. When releasing the pen from the surface it seems like the value for pressure runs down quickly to 0. But it's not possible to keep any value below $fc while the pen is on board. Occasionally when pressing a button the value can be 1 for a short period of time.

When nothing touches the board, TL is read as high, pressure is read as 0, x is read as 0 and y is read as $2a.

At the top edge of the board y is read as $26. Occasionally the value was read as $1c/$1e but then quickly changed to $26 without moving the pen.
At the bottom edge of the board y is read as $da.
At the right edge of the board x is read as $eb/$ee.
At the left edge of the board x is read as $30/$40/$50/$60 (this value varied a lot. Putting more pressure allowed to read $20)
With this high value as min for x around half of the canvas couldn't be drawn to, making the board practically unusable... might this be caused by aging hardware?

I'm not done evaluating the results of the timing tests but it seems like most of the delays calculated by Maxim are actually necessary:
After lowering TR it doesn't need much time to read the buttons but it needs more than 300us before the pressure high can be read.
Also there needs to be a delay after the edge of TH before the new value can be read. But it seems like the delay after the read before the next edge of TH is not necessary.

All timings are measured on a PAL SMS.
There needs to be a delay of 195 cycles (55 us) after lowering TR before buttons can be read, a delay of 595 cycles (168 us) after lowering TR before an edge on TH is recognized and a delay of 1842 cycles (519 us) after lowering TR before anything other than the buttons can be read.
There either need to be 328 cycles (92 us) between 2 consecutive edges on TH to get them recognized or there need to be 299 cycles (84 us) after an edge on TH before the new value can be read.

I've also attached the testroms:
The first byte is what is read from $dc after TR is set low, the second byte is pressure, third byte is X and fourth byte is Y.

GRAPHICS14 performs the same writes to port $3f like the rom with similar delays in between (every 2nd byte is just 00 for better readability) ; It should show results as described above
GRAPHICS13 is similar to GRAPHICS14 but it produces more edges on TH to see what is read after the 6th state. (it doesn't have the 00s in between the values yet) ; It should show results as described above
GRAPHICS15 is the same as GRAPHICS14 but it tests if a reset also occurs when TH is kept low when rising TR ; It should show same results as GRAPHICS14
GRAPHICS19 tests if a reset also happens when the last state isn't reached yet ; The first byte should work, the rest should read as 00s
GRAPHICS23 tests if an edge on TH is recognized when it happens with the same write that lowers TR ; It does - it should show the same results as GRAPHICS14
GRAPHICS29 tests if a reset occurs immediately after pulling TR high ; It doesn't - The extra byte should D followed by the low nybble of Y
GRAPHICS30 tests what is read before generating any edges on TR/TH ; First byte should show F0 (so buttons cannot be read) and rest works as usual

The timing tests:
The timing tests have variable delays in between events.
The length of the delay is shown in the 2 extra bytes and can be controlled using the Dpad of the 2nd controller.

GRAPHICStiming3 lowers TR and TH at the same time and reads the port after 270 + 4 * (value1 + value2) cycles ; With a sum of value1 + value2 < $189 everything works as usual. With $189 <= value1 + value2 < $18d the low nybble of the first byte is unstable and toggles between buttons and high nybble of pressure. For value1 + value 2 >= $18d the low nybble of the first byte corresponds to the high nybble of pressure.
GRAPHICStiming2 lowers TR, waits for 135 + 4 * value1, reads the buttons, 172 + 4 * value2 cycles later it lowers TH then reads the rest with very long delays in between ; With value1 >= $f the first byte shows the buttons. For value1 = $f and value2 >= $52 everything works as usual. If value2 = $51 or $50, the high nybble of the second byte occasionally shows the buttons. If $39 < value2 <= $4f, the high nybble of the second byte constantly shows the buttons, all axes work as usual. If value2 < $39, axes get unstable.
GRAPHICStiming lowers TR, reads buttons after enough delay, 429 + 4 * value2 cycles after lowering TR it lowers TH, waits for 146 + 4 * value1 cycles, reads the high nybble of pressure, raises TH, waits for 135 + 4 * value1 cycles, reads low nybble of pressure, ...; ($7f, $c1) stable, ($7f, <$c1) unstable, ($7f, <=$bf) buttons in pressure byte, ($41, $ff) stable, (<$41, $ff) buttons in pressure byte, ($29, $ff) axes stable, (<$29, $ff) axes unstable, ($7f, $a9) axes stable, ($7f, <$a9) axes unstable

Graphics Board testroms.zip (9.44 KB)

Author	Message
Maxim Site Admin Joined: 19 Oct 1999 Posts: 14761 Location: London	Posted: Wed Jan 07, 2015 1:48 pm
	1. No, it actually expects that I think. The board detection consists of reading the board and checking for no buttons pressed (giving 0 in the low four bits, impossible for other controllers), and the title screen then polls for a button press, never changing TH. 2. Yes, that's the time from the TH output to the next read. There's a little margin for error as I'm assuming consistent timings on the hardware side from the software instructions. Also, a PAL system has a slightly faster clock which means less time. 3. I think the board sets TL whenever it has pen values to transmit. This might be a direct "pen down" signal or it might be set only after the pen data is latched and ready to send.

ishiyakazuo Joined: 29 Oct 2014 Posts: 89 Location: Chicagoland, USA	Posted: Wed Jan 07, 2015 2:39 pm
	Maxim wrote 1. No, it actually expects that I think. The board detection consists of reading the board and checking for no buttons pressed (giving 0 in the low four bits, impossible for other controllers), and the title screen then polls for a button press, never changing TH. OK, good. Just to verify, all zeroes would be all buttons pressed, right? Then when a button is pressed, then they all go high (except for the pressed button)? Maxim wrote 2. Yes, that's the time from the TH output to the next read. There's a little margin for error as I'm assuming consistent timings on the hardware side from the software instructions. Also, a PAL system has a slightly faster clock which means less time. I suspect that the code won't need much time to operate (it's just reading the port, ANDing out the other bits, XORing it with what I previously saw TH to be, and if non-zero, put the next nybble on the data lines, and then gets ready for the next difference in TH). On an 8MHz micro, even if the while-statement is 20 cycles to evaluate and jump as needed, we're still in the realm of a few microseconds, so probably going to be fine here if we're talking ~150us (even if it's 20% faster on PAL machines or something... shouldn't be an issue) Maxim wrote 3. I think the board sets TL whenever it has pen values to transmit. This might be a direct "pen down" signal or it might be set only after the pen data is latched and ready to send. OK. I'm going to have to simulate this anyway, as the microcontroller I use doesn't have a dedicated touchscreen controller (and we don't need one -- it just makes touchscreen use a little easier). So I'll only set TL low after I've got the X/Y coords in the format that the software is going to ask (and I've detected a touch from the pen, of course). In any case, this is going pretty smoothly so far... I made a version of the firmware that's just missing the touchscreen code itself (everything else is implemented), and I'm using a whole 4% of flash and 3% of data storage. I think this micro will likely suffice ;)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14761 Location: London	Posted: Wed Jan 07, 2015 5:43 pm
	No, the buttons are active high logic. Bit 3 has to be zero to get past the title screen, bits 2 to 0 are the buttons and it wants them to go from all zero to at least one non zero. Note also that it reads the buttons and pen down signal both before and after lowering TR. Only after the first TH clock after lowering TR should it emit anything else.

ishiyakazuo Joined: 29 Oct 2014 Posts: 89 Location: Chicagoland, USA	Posted: Wed Jan 07, 2015 9:14 pm
	Ah, OK... they aren't active high on any other controller, are they? I can invert my logic though, no problem. Actually, that makes the logic easier. (I expected it was outputting zeroes until the board saw buttons, and then it'd switch to all high except one and go into active low logic. My mistake!) Made that change by inverting the button signals coming in with an XOR before I do anything else with them. (I don't care at all what the button values are -- the board itself wouldn't do anything with them.) I switch back to updating buttons + pen down after TR goes high, so that's fine.

ishiyakazuo Joined: 29 Oct 2014 Posts: 89 Location: Chicagoland, USA	Posted: Thu Jan 08, 2015 3:05 am
	I've put the initial code and schematic up on GitHub for people to look over if interested. https://github.com/ishiyakazuo/SMSGraphicsBoard That way, if I were to die tomorrow (and given the weather in Chicago lately, that's not an impossibility), this work shall not be lost. :)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14761 Location: London	Posted: Thu Jan 08, 2015 9:53 am
	I think every other controller uses active low, except when transmitting digital values (e.g. paddle position) when the data seems to be uninverted (although if the axis was reversed and the bits inverted, it would look the same). In theory, you could move a paddle to the exact 0 position and fool the board detection, likewise with the sports pad. The light phaser leaves the relevant pins unconnected so they are pulled high. On a control pad, it's impossible to press up, down, left and right at the same time.

ishiyakazuo Joined: 29 Oct 2014 Posts: 89 Location: Chicagoland, USA	Posted: Thu Jan 08, 2015 11:10 am
	Why'd you have to go and mention the paddle... now I'm thinking about "how can I add a paddle to this thing" :P (Probably would be pretty crappy to hold though with the touch panel on there, but again, not too difficult of a hardware design to duplicate.) Wonder if anyone would be interested in a paddle controller that has a switch that switches between Japanese mode and Export mode: Paddle Control v2.0.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14761 Location: London	Posted: Thu Jan 08, 2015 1:43 pm
	Since the paddle has stops at either side, a touch panel emulating it from one axis would be a reasonable approximation (it'd be good for Megumi Rescue). Less so for Out Run, where you really want rotation I think. (Interpreting circular motions on the panel would be tough as well.) Better to make it its own project, maybe after this one...

ishiyakazuo Joined: 29 Oct 2014 Posts: 89 Location: Chicagoland, USA	Posted: Thu Jan 08, 2015 2:32 pm
	Although I did consider the possibility of using the touch panel for it, I was really meaning to say that I was thinking about how I could put a rotary encoder or potentiometer somewhere on this thing ;) Once this is done, a lot of the code could probably be reused for the Paddle if a potentiometer is used. In other news, is anyone interested in helping with 3D modeling of cases for the Graphics Board? I can provide measurements as needed for the various pieces, but I'm pretty worthless on that side of things.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14761 Location: London	Posted: Thu Jan 08, 2015 7:25 pm
	I added some attempted timing diagrams here: https://github.com/maxim-zhao/smsgraphicboard/blob/master/Dasm/graphicboard.asm

ishiyakazuo Joined: 29 Oct 2014 Posts: 89 Location: Chicagoland, USA	Posted: Thu Jan 08, 2015 7:40 pm
	Cool, thanks. I'm hoping to get my PCBs cut apart this weekend, once it's a balmy -6C outside (much better than the -22C it was this morning). Then I'll solder up the prototype, try programming it... maybe get a repro cart of the software wired up... yeah, this'll probably still take me a good week or so.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14761 Location: London	Posted: Thu Feb 12, 2015 9:22 pm
	I'm getting quite far in my disassembly now and it's shown that emulating the pen as always down stops you from achieving certain things. In particular I think you can touch the screen, hold PEN to start drawing, lift the pen, then touch elsewhere to draw a line. It also allows you to operate menus without losing your last drawing position (provided you lift the pen), although I don't really see how that is useful. In operation, I don't see a meaningful difference between PEN and DO. I think there is never a time when you can use both. There are vestiges of 32KB of on cartridge RAM (mapped via the usual Sega mapper in slots 2-3), which it blanks on startup but then never touches again. Maybe at one time they hoped to operate on a bitmap in RAM and then render to the screen later? That would have allowed for a larger canvas, but you couldn't view it all at once. It might also have helped with the speed, although not by much. There isn't much that can obviously be done to improve the speed. It mostly works in pixel plotting mode, reading four bytes from VRAM to RAM (one row of a tile) and then modifying the relevant bit in each bitplane. That gets pretty slow in the fattest pen mode, where each point consists of nine pixels, especially as it then overwrites many of them. Maybe some tailored algorithms for drawing thick lines would help there. Since drawing is so slow, it reads and writes VRAM during the active display. It does this because it can get more work done overall this way, and also because it can remain responsive to certain things managed in the VBlank (mostly pen and sprite updates) while drawing. It doesn't let you interrupt the action in progress, though. This makes pixel plotting the main speed cost, so the algorithms themselves probably don't matter much, apart from when they can avoid pixel plotting entirely. For example, "square" filling optimises where it is setting all 8 pixels of a tile row. Circle filling doesn't because that's rather harder to know when you can.

ishiyakazuo Joined: 29 Oct 2014 Posts: 89 Location: Chicagoland, USA	Posted: Fri Feb 13, 2015 2:01 am
	Lots of interesting info there :) I've been fairly quiet on this for a few reasons... the largest of which was, I didn't have a way to test this. I don't have a large SMS cart collection, so taking one of my cartridges and replacing the ROM was out of the question. I went ahead and laid out my own 32KB ROM PCB. I'm hoping to get one soldered up next week (while I have the PCBs in hand, this weekend is already pretty fully booked). I did find one or two mistakes on the rev. A PCB. While they weren't deal-breakers, the analog measurement circuit wasn't as pristine as I'd like, so I added an inductor to help clean the reference voltage further. I also realized that I forgot the side solder pads to help hold the touchscreen connector down, which isn't a huge deal (could just tape the ribbon cable down to the PCB to avoid it wiggling too much), but I thought I'd like to do a little better. So I just got the rev. B PCBs, and while they have the pads, they're masked over! Oops! Nothing a little scraping by hand won't fix, but still... rev. C will likely be the one I end up being happy with. ;) My boss happened to discuss with me a particular problem that we were having, and it turns out that the circuit used for this is fairly close to the circuit needed to test something there, so I made some small modifications to accommodate that need as well. (On the plus side, that means I can play with this at the office somewhat in my spare time. Unfortunately, spare time has become a rare commodity!)

Bock Site Admin Joined: 08 Jul 2001 Posts: 8663 Location: Paris, France	Posted: Fri Feb 13, 2015 9:43 am
	Isn't onboard 32KB just a vestige of the possibility of saving your drawing on the cartridge?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14761 Location: London	Posted: Fri Feb 13, 2015 2:04 pm
	Maybe (I can think of more possibilities). The fact that it blanks it makes me think it's not persisted, though.

ishiyakazuo Joined: 29 Oct 2014 Posts: 89 Location: Chicagoland, USA	Posted: Fri Feb 13, 2015 2:49 pm
	Unless the blanking was done in a fit of rage when that feature was removed, like pouring salt on the land ;) But I think your initial explanation is probably more plausible.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14761 Location: London	Posted: Wed Mar 11, 2015 8:47 pm
	My disassembly is now complete, except for some tidying up and coming back to some questions. All RAM is accounted for, graphics are pulled out to PNGs, there's lots of enumerations for avoiding magic numbers in there. https://github.com/maxim-zhao/smsgraphicboard/tree/master/Dasm Some of the code seems to be pretty well optimised (rectangle filling), some seems pretty sub optimal (drawing thick lines, filled circles... most parts, actually). It might be relatively easy to add a line drawing feature (beyond the pen point interpolation I mentioned above, letting you define the start and end points on-screen). Undo is not going to happen. Loading and saving to SRAM is definitely possible (you could fit two into 32KB, or maybe try compression to fit more). I'll probably never do any of this stuff... but it might be fun for someone else when the repro hardware exists.

ishiyakazuo Joined: 29 Oct 2014 Posts: 89 Location: Chicagoland, USA	Posted: Sun Apr 26, 2015 12:28 pm
	Hi there, Just to give an update on this -- I haven't forgotten about it, but as I alluded to a bit in my previous post, I've become super busy at work, and when I get home, I don't really much feel like working on code/electronics. On the plus side, I think there's light at the end of the tunnel on the work side of things (my project is nearing completion), and the similar project I had to do for work is complete now, so I think once I get back to this, it shouldn't take very long to get it done. Anyway, I had mentioned the possibility of making your own paddle controller with a similar circuit, but someone has beaten me to it: http://www.raphnet.net/electronique/sms_paddle/index_en.php Thought that might be interesting for some to see.

Bock Site Admin Joined: 08 Jul 2001 Posts: 8663 Location: Paris, France	Posted: Sat May 02, 2015 11:55 am
	Hey, I may have to pack the board in storage in France (currently cleaning up our London place for travelling for a few months). While it is by my side, is there any test I could perform to help testing the HW ?

Calindro Joined: 14 Apr 2013 Posts: 624	Posted: Mon May 04, 2015 5:54 pm
Calindro Joined: 14 Apr 2013 Posts: 624	Hey guys, Omar and me have done a lot of testing and basically we could confirm everything that has been concluded before: Initially the data pins are low, TR and TH are high. After lowering TR you can read the buttons (state 0) from the data pins. When an edge on TH is detected and the state number is less than 6 the state number gets increased. The following values can be read from the data pins in the given state: 0 : buttons 1 : pressure high 2 : pressure low 3 : x high 4 : x low 5 : y high 6 : y low Pulling TR up resets the state counter to 0. The reset takes some time. So right after pulling TR up the value for the current state can still be read from the data pins. When the pen (a finger works as well) touches the board TL is pulled low and pressure is set to $fd (most of the times). When applying some force the value for pressure can also reach $fe. At the top left corner Omar could also get $fc for pressure. When releasing the pen from the surface it seems like the value for pressure runs down quickly to 0. But it's not possible to keep any value below $fc while the pen is on board. Occasionally when pressing a button the value can be 1 for a short period of time. When nothing touches the board, TL is read as high, pressure is read as 0, x is read as 0 and y is read as $2a. At the top edge of the board y is read as $26. Occasionally the value was read as $1c/$1e but then quickly changed to $26 without moving the pen. At the bottom edge of the board y is read as $da. At the right edge of the board x is read as $eb/$ee. At the left edge of the board x is read as $30/$40/$50/$60 (this value varied a lot. Putting more pressure allowed to read $20) With this high value as min for x around half of the canvas couldn't be drawn to, making the board practically unusable... might this be caused by aging hardware? I'm not done evaluating the results of the timing tests but it seems like most of the delays calculated by Maxim are actually necessary: After lowering TR it doesn't need much time to read the buttons but it needs more than 300us before the pressure high can be read. Also there needs to be a delay after the edge of TH before the new value can be read. But it seems like the delay after the read before the next edge of TH is not necessary. All timings are measured on a PAL SMS. There needs to be a delay of 195 cycles (55 us) after lowering TR before buttons can be read, a delay of 595 cycles (168 us) after lowering TR before an edge on TH is recognized and a delay of 1842 cycles (519 us) after lowering TR before anything other than the buttons can be read. There either need to be 328 cycles (92 us) between 2 consecutive edges on TH to get them recognized or there need to be 299 cycles (84 us) after an edge on TH before the new value can be read. I've also attached the testroms: The first byte is what is read from $dc after TR is set low, the second byte is pressure, third byte is X and fourth byte is Y. GRAPHICS14 performs the same writes to port $3f like the rom with similar delays in between (every 2nd byte is just 00 for better readability) ; It should show results as described above GRAPHICS13 is similar to GRAPHICS14 but it produces more edges on TH to see what is read after the 6th state. (it doesn't have the 00s in between the values yet) ; It should show results as described above GRAPHICS15 is the same as GRAPHICS14 but it tests if a reset also occurs when TH is kept low when rising TR ; It should show same results as GRAPHICS14 GRAPHICS19 tests if a reset also happens when the last state isn't reached yet ; The first byte should work, the rest should read as 00s GRAPHICS23 tests if an edge on TH is recognized when it happens with the same write that lowers TR ; It does - it should show the same results as GRAPHICS14 GRAPHICS29 tests if a reset occurs immediately after pulling TR high ; It doesn't - The extra byte should D followed by the low nybble of Y GRAPHICS30 tests what is read before generating any edges on TR/TH ; First byte should show F0 (so buttons cannot be read) and rest works as usual The timing tests: The timing tests have variable delays in between events. The length of the delay is shown in the 2 extra bytes and can be controlled using the Dpad of the 2nd controller. GRAPHICStiming3 lowers TR and TH at the same time and reads the port after 270 + 4 * (value1 + value2) cycles ; With a sum of value1 + value2 < $189 everything works as usual. With $189 <= value1 + value2 < $18d the low nybble of the first byte is unstable and toggles between buttons and high nybble of pressure. For value1 + value 2 >= $18d the low nybble of the first byte corresponds to the high nybble of pressure. GRAPHICStiming2 lowers TR, waits for 135 + 4 * value1, reads the buttons, 172 + 4 * value2 cycles later it lowers TH then reads the rest with very long delays in between ; With value1 >= $f the first byte shows the buttons. For value1 = $f and value2 >= $52 everything works as usual. If value2 = $51 or $50, the high nybble of the second byte occasionally shows the buttons. If $39 < value2 <= $4f, the high nybble of the second byte constantly shows the buttons, all axes work as usual. If value2 < $39, axes get unstable. GRAPHICStiming lowers TR, reads buttons after enough delay, 429 + 4 * value2 cycles after lowering TR it lowers TH, waits for 146 + 4 * value1 cycles, reads the high nybble of pressure, raises TH, waits for 135 + 4 * value1 cycles, reads low nybble of pressure, ...; ($7f, $c1) stable, ($7f, <$c1) unstable, ($7f, <=$bf) buttons in pressure byte, ($41, $ff) stable, (<$41, $ff) buttons in pressure byte, ($29, $ff) axes stable, (<$29, $ff) axes unstable, ($7f, $a9) axes stable, ($7f, <$a9) axes unstable Graphics Board testroms.zip (9.44 KB)

Forums

View topic - Sega Graphic Board v2.0 reverse engineering