GBS8200 - teasing the schematics out of the board

[J. Danen]

So I happened to notice that for such a popular board, the GBS8200 sure does not have any schematics floating around (either that or I am that bad at googling. One bad decision later, this repo was started. Beware, the schematic is far from done (or professional), and I can't promise any regularity in the updates - only so many hours a day, y'know. In the meanwhile, feel free to take a peek at what is already there, point out any mistakes, and perhaps explain to me, why does the I2C bus seem to connect to anything but the datasheet-listed I2C pins on the MTV230.

[J. Danen]

There! Nearly a year later, it finally looks like it's finished. Any input on the remaining mysteries or licensing would still be appreciated, though.

[kitty666cats]

Much respect! Surprising this wasn’t already available for an unfathomably massively produced board that’s been available for probably 2+ decades. You’ve done a passion project FOR a passion project

[J. Danen]

Much respect! Surprising this wasn’t already available for an unfathomably massively produced board that’s been available for probably 2+ decades. You’ve done a passion project FOR a passion project

Thank you! I had no idea the board was that old, although, knowing that, the somewhat archaic microcontroller now makes sense. I'll have to admit, I'm not sure how useful the schematics are. In theory, one could upgrade them to include the mods commonly done to the board these days, but frankly, I'm not sure if the costs of spinning up an entirely new board could actually compete with the original GBS + cost of mod parts. Would be a lot neater, though. Admittedly, now I'm somewhat mystified by the results I got, like the same old aforementioned weirdness with I2C pins being connected to the "wrong" pins. I said in the repo README that I was not going to dump the firmware, and need to touch some grass instead, but in this hemisphere, all the grass is currently under snow, so....Datasheet says the MCU has a programming mode that lets you read out the current f/w over I2C. Seems pretty easy to do, but the 8051 is an arcane architecture to me, and while I'm fairly comfortable in C, I've yet to actually seriously dabble in assembly, so analysing said dump is a whole other can of worms. (And that's if we can get an 8051 disassembler to play nice, remember, this MCU is an extension of that thing). If someone else is willing to take a crack, though, I suppose I could go ahead and do the dump, along with the EEPROM.

[fernan1234]

Very cool to see this. Who know what may come out of it but it seems like this lays a lot of groundwork for squeezing untapped potential from the GBS beyond what rama was able to do.

It always felt to me like the GBS has more potential in particular as an analogue-to-analogue video processor/converter.

[J. Danen]

Very cool to see this. Who know what may come out of it but it seems like this lays a lot of groundwork for squeezing untapped potential from the GBS beyond what rama was able to do.

It always felt to me like the GBS has more potential in particular as an analogue-to-analogue video processor/converter.

That depends...I wouldn't expect any groundbreaking picture quality improvements, but it could make the board into sort of a video Swiss army knife. You can pretty much skim through the scaler chip datasheet, and if some feature is listed there, the board should be able to do it. I'm myself pretty excited for any potential digital RGB shenanigans, as that means you can use the GBS-8200 as a test bench for displays salvaged all kinds of old electronics (I have one from an old GPS navigator lying around, but it has a fine pitch mezzanine connector that I can't find a breakout board for). Not sure how useful would it be in the arcade/retrogaming scene, but hey, that's up for y'all to decide.

[Josh128]

I wish a 1080i and 540p mode could be added to the GBS-Control firmware.

[fernan1234]

I wish a 1080i and 540p mode could be added to the GBS-Control firmware.

Would be really neat for HD CRTs. So would 480i downscaling (or even upscaling for the heck of it) for SD CRTs.

If I recall correctly rama mentioned there was a limitation that prevented interlaced output, but maybe this could be overcome eventually with the board reverse engineered.

[J. Danen]

I wish a 1080i and 540p mode could be added to the GBS-Control firmware.

Would be really neat for HD CRTs. So would 480i downscaling (or even upscaling for the heck of it) for SD CRTs.

If I recall correctly rama mentioned there was a limitation that prevented interlaced output, but maybe this could be overcome eventually with the board reverse engineered.

On that - can't access the datasheet ATM but the Tvia webpage explicitly mentions 1080i output capabilities, so that sounds within the realm of possibility. No guarantees though. Did rama state any particular problem with it? I don't quite feel like digging through the whole GBS-Control development topic to find out.

[J. Danen]

So I have not kept my promise of touching grass. Instead I have managed to find out that at least on my unit, the MTV230M lives at slave address 0x3F while in ISP mode. My brain is a bit cooked to actually get any data out of it atm, but I think it should be fairly trivial.

EDIT: due to my chronic inability to just leave things be, I've got to reading the f/w out. It works, logic analyzer shows the MTV230 is responding with SOMETHING, but for some reason, the ATMega328 I'm using won't recognise trat it has received the data, despite ACK'ing everything on the line.

FURTHER EDIT: The f/w has been fished out. Now I just have to figure out how to coax it into a less cursed format - it's currently in an excel sheet, don't ask how that happened.

[J. Danen]

Pardon the third post in a row, but I think this is interesting enough to deserve a bump. I have since wrangled the firmware out of the excel sheet and into a neat BIN file. On a spurt of curiousity, I went around digging for strings, and found some that I don't think I've ever seen in the menus. There are entries for a debug menu, with options to reset EEPROM and enter an ISP mode, references to S-Video, which this board, AFAIK, does not have, a bunch of display modes like "1080i60", "480P", etc., even some strings that sound like presets from a TV menu - "Day", "Night", "Standard", "Vivid", "Sharp", "User". And to complete things, a copyright message: "Copyright: XiangChengZhai". A cursory Google search revealed no results.

What's the preferred method for sharing files here? I don't see an attachment system, so just a link to one of those MegaShareUpload sites? Wouldn't hurt for someone else with a smidge of understanding of assembly to take a look.

[SuperSpongo]

Very cool!
I chuckled at the firmware ending up in an excel sheet

[Josh128]

J. Danen, thank you for your hard work and dedication to this project. Please post as often as you want about this. It would be extremely cool if additional resolutions and options would be able to be enabled via this documentation.

[J. Danen]

I just can' t get enough of this thing, can I?

So I got my hands on an I2CDriver, and figured I could give on-the fly patching a try. Started wtih an attempt to change the "Main menu" title, and, well, changed it got - to complete gibberish though. It appears that the MTV230 has trouble writing to the flash, I2C seems to be fine, transmissions get ACK'ed, but when reading back the supposedly reprogrammed regions of flash, well, some bytes have assumed random values, some haven' t changed at all. No idea what's going on in there. Might be that my I2C driver is garbage, might be that the chinesium content in the GBS8200 is just too high. Or maybe you're supposed to erase the flash before programming it, IDK, don't exactly have a good feeling about that.

EDIT: removed an f-bomb, yesterday was just not good.

[Unseen]

but when reading back the supposedly reprogrammed regions of flash, well, some bytes have assumed random values, some haven' t changed at all. No idea what's going on in there. (...) Or maybe you're supposed to erase the flash before programming it, IDK, don't exactly have a good feeling about that.

It's pretty common that flash memories need an explicit erase command because the cell endurance is mainly based on erase cycles instead of writes. If you notice that you can change bits only one way - usually from 1 to 0 - that is a very strong sympton that you need to do an explicit page/block/sector/chip erase before you can write your data.

[J. Danen]

but when reading back the supposedly reprogrammed regions of flash, well, some bytes have assumed random values, some haven' t changed at all. No idea what's going on in there. (...) Or maybe you're supposed to erase the flash before programming it, IDK, don't exactly have a good feeling about that.

It's pretty common that flash memories need an explicit erase command because the cell endurance is mainly based on erase cycles instead of writes. If you notice that you can change bits only one way - usually from 1 to 0 - that is a very strong sympton that you need to do an explicit page/block/sector/chip erase before you can write your data.

Ah, sounds about right, will give that a try

[J. Danen]

I am pleased to announce that the experiment has been a great success - i.e. the main menu title now proudly displays my name.

Although it looks pretty nifty, there's not actually much that I can do with it. Changing around constants, sure, but for actually changing functionality, I'd need to start rewriting the firmware, which implies either learning 8051 assembly or hoping that SDCC can handle this thing. I'm a bit reluctant to actually go and try SDCC, since, as far as I can understand the datasheet, the ISP peripheral is controlled entirely by software, and if, due to some bug, my custom f/w would fail to enter ISP mode, I'd have essentially bricked the GBS8200.

[kitty666cats]

reluctant to actually go and try SDCC, since, as far as I can understand the datasheet, the ISP peripheral is controlled entirely by software, and if, due to some bug, my custom f/w would fail to enter ISP mode, I'd have essentially bricked the GBS8200.

Do eeeeet! They cost like five cents

[SuperSpongo]

This sounds very promising. I'm always up for pooling some money together for the sake of development. I'm sure others have a few bucks to spare as well. What's a board nowadays, 40 bucks? I'm sure that's feasible, right?

[J. Danen]

reluctant to actually go and try SDCC, since, as far as I can understand the datasheet, the ISP peripheral is controlled entirely by software, and if, due to some bug, my custom f/w would fail to enter ISP mode, I'd have essentially bricked the GBS8200.

Do eeeeet! They cost like five cents

The cost isn't that much of an issue, accumulation of "it's technically not trash!" is . That said, with a dead MCU, it'd be a perfect candidate for GBS-C surgery, so, a'ight, will see about it.

This sounds very promising. I'm always up for pooling some money together for the sake of development. I'm sure others have a few bucks to spare as well. What's a board nowadays, 40 bucks? I'm sure that's feasible, right?

Seems like you can still nab one for sub-20 USD. Frankly, setting up the payment would be more of a PITA than just buying the board out of my pocket :p Ah well, might as well get started on a h/w library for the MTV230M, I'm pretty sure there isn't one floating around quite yet.

[J. Danen]

You b******s can be convincing.... I've started work on a small software tool for reprogramming the MCU, since I CBA to do it by hand from the CLI every time... will let y'all know how it goes

EDIT:: Im postoponing this until late autumn, there's too much stuff to do outside ATM

[SuperSpongo]

Stupid sunny weather!

[J. Danen]

It rained, so the reprogramming tool is done. Well, kinda. Take a peek at the GBS8200_reprog repo. It runs on my machine anyhow.