CharlesMouse

Ok, ok... not quite done yet. While paranoia dictates re-re-re-checking everything before I send off for some PCB's to be made I hummed and harred about that VGA connector. I had gone for a 9Pin jobbie to save any confusion as this board is 15Khz only... but I've changed it for a 15Pin version. While that might cause some confusion 15Pin cables are much easier to come by. Yes, one could use a serial cable but they aren't generally as well shielded as proper video cables - the base purpose of this board is better video output after all. Also as anyone without SCART, the good fortune to have a 15KHz compliant LCD, or a good old CRT monitor, will probably use a converter box a 15Pin connector is probably more useful. So... I 'think' that's it. At least until PCB's come back and I (almost) inevitably have to go chasing the various mistakes I've not noticed. PS I had to do my own footprint for the 9958 as the 64Pin package and the 1.78mm pin width aren't standard. I don't really want to solder a precious 9958 to an untested design... does anyone know where I could buy a socket that would fit this IC, or some weird-ass pin-strips?

Thanks for the info, I can't say I have much (any) familiarity with MSX machines. It's actually nice to know device access as supposed to go through the BIOS, that does indeed potentially help running MSX games on Coleco hardware. Not within my skill-set I'm afraid, but you never know. For now I'll likely stick with this being a GFX card for Coleco systems. I've added a pass-through connector for other devices such as the SGM, and if this board works I intend to design add-ons such as an AY and RAM board. With that in mind I think a case with room for internal and external expansion would be nice... something like this?

Deep breath... I really started this particular exploration for something to do while waiting on PCB's and didn't expect to come this far so fast... indeed I really expected to quickly find such an undertaking to be completely beyond me. With that in mind below is my 'final' design, for now. Much to my surprise I guess I'm close to sending off another order to Seeed. Nothing is set in stone so if anyone wants to chime-in be my guest. Here's the feature-set for now: -Yamaha V9958 based expansion board for both the Colecovision and ADAM -Primarily as an Old School way to get better video output from Coleco's machines -Should be fully compatible with Coleco's implementation of the TMS9918a -MSX2+ graphics capabilities within reach, including an 80 column mode -Apart from a superset of Coleco's standard addressing it also supports MSX(2(+)) addressing -I've added a side port pass-through so current devices can be used too - I have some thoughts of my own -While port clashes mean I can't add a fully MSX compatible sound chip there's still the SGM... ...even if I can't bring full MSX2+ compatibility this is close enough to make porting games fairly straightforward If this design actually proves to be functional wishful thinking means I'd really like to see it become popular and somewhat supported. I'm not in a position to go in to production but would be very happy for anyone else to do so... as an example an updated SGM with close to MSX2+ compatibility would be awesome. "...and I'd like a toilet made out of solid gold but it's just not on the cards, baby." Pie in the Sky aside, here's the latest iteration:

You're most kind ? Further progress, of a sort... If MSX software compatibility is possible a sound chip will be needed, and it seems I can squeeze an AY on the board without making it too much bigger. Although I wish I could come up with a more efficient method to decode the AY... I'm also not confident I've got the addressing right for functional SGM compatibility. Sadly the real fly in the ointment, and seemingly the explanation as to why the SGM uses the ports it does for sound, is Coleco's video addressing clashes with the ports MSX machines use for audio. Oh well that puts an end to thoughts of just playing MSX(2) games on Coleco systems, some modifying will be needed. FWIW I've attached my initial schematic for V9958 and AY sound but I guess I'll have to drop that idea. Video card only it is, and at some point I'll also do a pass-through board so it can be used with an SGM. Wishful thinking, I know, but if this plan actually works out I'd be very pleased if the makers of the SGM brought out a update that includes a V9958. For now I'll call this an RGB card for Coleco systems that has potential to do much more.

Evil goings on with XOR gates... So here's the issues: 1) While accessing the 9958 from A0H / A1H is safe if you think you are accessing a 9918 (all software for now) doing so from BEH / BFH won't as the 9958 sees A1 and if it's high you end up in the extra addressing modes - no good! So if it's being accessed from BEH / BFH we can assume software is expecting a 9918 and we need to flip that A1 bit to zero. Under all other circumstances all should be well so don't flip that bit... ...as it happens A2 is also 1 for BEH / BFH and a zero for all other reasonable circumstances so if we XOR A1 with A2 and feed that output to the 9958's Mode1 pin we get a zero when we are certain we're in 9918 mode and unchanged action otherwise... I think! 2) What about 9958 mode..? Looking at the bit pattern for A0H... A1H (Coleco) and 98H... 9BH (MSX2) the only difference that the Coleco decoding logic sees is on A5 - one for the Coleco and zero for the MSX. So, it seems, I could just tie the A5 input for the DeMUX IC high, but for some reason that doesn't feel quite right to me... So with some spare XOR gates I'll feed an inverted A5 into another XOR along with A5 which should 'select' a logic high on A5 regardless, ah-hem! Having checked for potential 'gotchas' the Coleco's method of decoding ports is a bit, er, dodgy. It seems it will 'decode' a fair old range of addresses as 'good': Coleco Range A0 1010 0000 - Data A0=0 Mode(0) A1 1010 0001 - Regs A0=1 Mode(0) ...to... A2,A3 or AA, AB - Bad if 9918 mode! AF 1010 1111 B0 1011 0000 B2,B3 or BA, BB - Bad if 9918 mode! ...to... BE 1011 1110 - Data A0=0 Mode(0) BF 1011 1111 - Regs A0=1 Mode(0) ...and now likewise for the MSX2 decoding I've added. Happily it looks like: 1) There are no obvious clashes 2) 'Unsupported' ports are nearly all fine... ...because of the way I'm attempting to trap and correct BEH / BFH calls to what's expected to be a 9918 there are two areas where it all goes a bit runny if you think you're calling a 9918. At this point I'm declaring 'good enough'. So: With the addition of a 74LS136 this board should behave as the native VDP if you access it in a reasonably sensible fashion. If called via A0H... A3H you get full access to the 9958 in a 'Coleco friendly' manor. If called via 98H... 9BH you get full access to the 9958 using the standard MSX2 addressing. Given I started this project as a bit of a "what if?" it's coming along better than I'd hoped so it might actually see the light of day. I'm feeling quite pleased with myself so now's the time to bring me down with a bump by telling me all the things I've done wrong:-

Oh, well... still plugging away. Because, understandably, Coleco chose BE & BF for the 9918's ports it won't be straightforward to just add a couple more ports to that address: Coleco 9918 BC 1011 1100 BD 1011 1101 BE 1011 1110 - Data A0=0 Mode(0) BF 1011 1111 - Regs A0=1 Mode(0) C0 1100 0000 C1 1100 0001 MSX2(+) 9938 (9958) 98 1001 1000 A1=0 Mode1 A0=0 Mode0 Data 99 1001 1001 A1=0 Mode1 A0=1 Mode0 Regs 9A 1001 1010 A1=1 Mode1 A0=0 Mode0 Palette 9B 1001 1011 A1=1 Mode1 A0=1 Mode0 Regs If Coleco had chosen BC and BD as the 9918 port addresses it would have been easy to add two more ports to that but the bit pattern just doesn't work for the 9958 where the current ports are and gets worse if you try for the logical option of the two addresses either side. Options: 1) I use the ports at BC and BD and play silly bugg*rs with some NOT gates to make the bit pattern to line up as the 9958 expects. The down side is coding for the 9958 would be less logical as the port order would be backwards. 2) I just say "scr*w it" and keep the Coleco addressing for compatibility (with a couple of NOT gates) and do the standard MSX2 addressing at 98-9B. Great for compatibility, if more IC's... ...do addresses 98-9B clash with anything on the Coleco side..? I guess a quick look at the TRM is in order. Another *EDIT* Ah! It seems the Coleco 9918 ports are duplicated at A0H, so: MSX2(+) 9938 (9958) 98 1001 1000 A1=0 Mode1 A0=0 Mode0 Data 99 1001 1001 A1=0 Mode1 A0=1 Mode0 Regs 9A 1001 1010 A1=1 Mode1 A0=0 Mode0 Palette 9B 1001 1011 A1=1 Mode1 A0=1 Mode0 Regs Coleco Again A0 1010 0000 - Data A0=0 Mode(0) A1 1010 0001 - Regs A0=1 Mode(0) A2 1010 0010 A3 1010 0011 That will do rather nicely for the 9958 addressing too. ? It doesn't look like that clashes with anything and as a bonus it doesn't look like the standard MSX2 port range is used either so that could be an option. So...time to wrap my head around some addressing: I still need to have a think about how I do the addressing. If I just go with the way Coleco did it (great, less thinking for me!) and programmers always access the VDP via the A0 base address all is good. But if the BE base is ever used with a 9958 attached that won't fly... ...and while I could just flip the 'naughty' A1 bits for BE/BF addressing that would mess up A0-A3 addressing. Hrrm... Maybe I stick with my first inclination and leave the Coleco addressing as is (with A1 bit flip for the 9958) and add MSX2-like addressing on top. *sigh* more IC's...

Well, I had a bit more of a fiddle and things seem to have come along rather more nicely that I expected. Having taken a look at the Colecovision schematic, rather than the ADAM one, the memory addressing is much neater and fully in line with the way Coleco did it. I've also changed some other bits I guessed at that turned out not as Coleco intended. I want this to be seamlessly compatible. Mode0 on the V9958 is connected to A0 as Mode is on the TMS9918a while Mode1 is connected to A1 - seemed logical to me!* *EDIT* Actually I need to think about this again! Of course A0, along with the MUX, decides between ports ...BEH (Data) and ...BFH (Registers) for the TMS9918a. So... as far as I can see 9918 and 9958 Mode and Mode0 lines are equivalent, it's Mode1 on the 9958 that brings the extra fun. If I attach that to A1 on the same base address that won't fly! I guess I need to choose another pair of base address for Mode1 and hook that line to A0 too... I must go see if I can find an MSX2+ schematic from somewhere to check. So, at worst, this should be a compatible GFX card that brings RGB out to the table along with less sprite flickering; assuming I understood the docs correctly. At best this adds all the extra goodies that come with the V9958 for those who want to code for them, along with a cr*p ton of extra RAM. Thoughts: Proper, non serial, 80 column support would be nice. This potentially opens the door to MSX2(+) ports - running code directly could be achievable if I add an MSX-compatible addressing mode. If I go totally bananas it might be fun to add a Y8950 to the mix, and a smidge of RAM, to cover the full MSX experience and possibly SGM duties too. Rationale: I went for a V9958 because they seem to be readily available, and are software compatible with the TMS9918a. Old school RAM because 41464's aren't hard to find. Having looked in to using SRAM I couldn't see any benefit. With the extra logic required using SRAM wouldn't save space and could bring up hard to fix timing issues. Full VRAM and XRAM support because it wasn't a problem and adding stuff later is more of a pain than not fully populating a design. 15Khz VGA because it was easy enough to do and isn't a huge hassle to use with modern equipment. I guess the V9958 carries the lines for encoding video for other formats, but that's a whole bunch of extra IC's and thinking to do. Suggestions: If there's interest I'd appreciate questions and thoughts on what anyone might want from such a board. For instance I'm currently of a mind to do a separate port expander dongle rather than a pass-through connector.

Bored waiting for the latest iteration of 'my' 80 column / serial / expansion card to turn up... boy, have I made a meal of that one! I do hope I get it to work eventually. ...so in a fit of stupidity I bought a V9958 off fleaBay, and then realised I'd have to do something with it. So here's another bone for me to gnaw on: Assuming I get round to making a working version (you never know, miracles may happen) it's an old school GFX upgrade: -V9958 and, potentially, all the benefits that come with that -RGB out, sorry 15KHz only -196k split between 128k VRAM and 64k XRAM -More sprites supported per scan line I've not tried to route it as yet; partially as I need some time to look for all the mistakes I've certainly made, and partially because it will be a SOB to route. On that latter subject I guess I need to add a pass-though for SGM users which will add to the 'fun'. Maybe, apart from better video, such an upgrade could open the door to MSX2 software and a 'native' 80 column mode. So... something worth pursuing? Thoughts..?

Hi Chaps, Yes I agree it's hard to justify stuff beyond an AtariMax, a decent game pad, and possibly an SGM, all of which are already covered. I really like the IDE card I have but I admit it doesn't get a lot of use, especially with Seam Myers excellent ADAMNet Drive available. Still, it's nice to be able to boot CP/M (TDOS) from a 'hard drive'. I'm kind of throwing out ideas to see if any stick as once (I sincerely hope!) current projects reach a successful conclusion I'm a bit stuck for ideas... ...I got started with the idea of using my ADAM to finally learn CP/M and got a bit distracted with things to make the CP/M experience on this system a bit better. Also as my daughter built and RC2014, with a bit of help, and that's primarily a CP/M machine that with the right expansion will run Coleco software it's been fun to try to approach the same functionality from opposite directions. (How I wish MIB had gone for an SIO/2, or even a R6551, instead of a SCN2681 for their serial design. I would probably be enjoying an 80 column display by now instead of continuing to struggle) PS I shudder to ask this question because I'm even less knowledgeable when it comes to video than other stuff, and I'm happy with the warm fuzzy feeling from my ADAM's display, but is there any mileage in my looking in to that? (A better old school analogue display, none of this fancy HDMI stuff for me!)

As a bit of an experiment I came up with a basic design for an ultra simple IDE card for the ADAM. Well, to be honest the idea is heavily cribbed from a well known design for the ZX Spectrum computer. Why bother when there's a perfectly good solution for sale? Well I have one of my own and it's excellent, but variety is the spice of life and as usual I like to see about DIY options for my own amusement. Pro's: -Literally a one chip design -Could be botched together as a 'dead bug' if you were so inclined -I've got a preliminary ADAM slot schematic done-ish Con's: -To keep things as simple as possible it's an 8bit interface (IDE is 16bit-ish) -That means 1/2 of your media goes to waste - hardly a biggie, and with a little trickery I might be able to use an SD card in SPI mode to solve that -I'm, um, stuck for driver software So... Would there be any interest in such a DIY project? I'd say this one has to be DIY only as I don't want to tread on commercial toes in a small market. The easiest route to functional drivers would be to ensure such an interface is software compatible with the excellent commercial one already available... Does anyone feel it's ok to share the workings of that version before I consider the long way round and get out my multimeter..? PS For my part I'm addressing all the things I'd consider useful for an ADAM owner that are potentially within my reach. (maybe!) But I'm open to suggestions.

Hi, I'm glad you like the look of this project, I hoped it would prove useful to some. On the subject of "where to buy" I'm afraid the interest for me is in the design process and learning about the system I'm currently attacking, I don't generally sell completed versions or kits. Having said that I really don't mind if anyone else wants to and while I have spare PCB's I'm happy to discuss sending one to anyone who can make use of it. Feel free to PM me. To the thread in general my "master plan", such as it is, is not only to provide useful designs for others where I'm able, but also to help get others in to soldering up their on kit possibly as a starting point to make their own stuff from scratch. -It is fun, honest! -Soldering is dead easy with a little practice -PCB design has a fairly steep learning curve initially but gets easier -PCB manufacture couldn't be simpler -As time goes by goodies for somewhat unloved machines like the ADAM will only come from enthusiasts.

Yes I know... ...but here's an update. I added a latch to the AVAIL signal so that's functional logic with any luck. I also added a composite out for where mixing with the 9918 isn't desired.

Right, details. If anyone can tell me what's still wrong I'd appreciate the help. If nothing I'll assume it's just my current board is over-patched and too unstable to run. So here goes: Raspberry Pi: Seemingly all good, and I have been sure to check I've got it communicating at the same baud setting as the ADAM, but no luck. The best I've managed is having the keyboard input under TDOS go berserk when I set it up to use a keyboard attached to the Pi for input just to see if I was getting any communication - I guess that suggests something is going on! FTDI Adaptor: As my board is basically a serial interface I tried using an FTDI adapter hooked up to a PC with TeraTerm acting as a console so I'd have full control over communication options. Also to see if it was a PI-specific issue. Again no joy on either serial port including trying alternate baud rates and parity settings, etc. Pi Serial board: As far as I can tell I've patched all the mistakes (maybe not!) and swapped out all the IC's for which I had replacements... still waiting on some IC's. Design: So I took another look at the MIB schematic (see attached) and the GAL code (see attached) and re-did the board from scratch (see attached). Improvements over the old design: -A much neater board, with fewer components to source -All mistakes I'm aware of fixed -Some changes to resistor values and logic in an attempt to improve stability of the board ...all good but my 'worry' is while I've come up with a 'better' design the fundamental function isn't any different from the way my thoroughly patched prototype board is constructed, and not working! Specifics: -Schematic: I can't see any wiring mistakes on my part, the MIB original, or my interpretation of it's function -GAL: As far as the serial ports are concerned all the MIB boards are the same. So drivers shouldn't matter, and the schematic I'm using should be fine too. The GAL functions I need to reproduce are as follows: Duart RESET 1CH (Output) - SRST = IORQ & WR & A[7..0]==1CH This is handled on my schematic with a couple of NAND gates and a 4048 (the one at the bottom) - it looks good to me but have I done something stupid..? Duart I/O space 10H-1FH - SCE = IORQ & A[7..4]==0001B Again handled by a 4048, the one higher up on the schematic. One of my mistakes, which I hoped patching the board would see the board come to life, was not noticing the IO space is a range not a single address. The logic only looks at A4-A7 for addressing. I handled this by just grounding the unused lines on the 4048. Again this now looks good to me but am I wrong? I've added a couple of NAND (NOT) gates on the input line for the Pi for 'signal conditioning' in the hope this might improve reliability. I also added a test header so I can mess about with the communication lines to the Pi in case I got the wiring wrong - I don't think so, but I did check this on my prototype without any improvement. As I'm running my board for TTL level serial I also changed the ports to standard FTDI ones and added some current limiting resistors for a bit of protection - again I'm not aware this will be a problem but as I'm not experienced with this UART you never know... My issue is I have what I believe to be a good design that is compatible with any of the MIB drivers but my admittedly heavily patched prototype board doesn't work. I'm therefore wondering what I've missed / done wrong and as a result a bit reluctant to send of for a new batch off boards based on this latest design in case they are duds too. Thoughts would be very much appreciated. PS: In case any are worried about this stripped-down iteration never fear. Courtesy of the breakout header I already have daughter boards designed for ROM, Parallel, AY sound... but they are of no use if the primary board won't work. FW_MIB3G1.pdf MI_MIB2B_SCH.pdf

Hi, sorry for the really slow reply - thanks very much for the driver file and the most helpful advice... Unhappily I've spent the last few days struggling to get the card working, but with no luck. From your helpful advice I'm now pretty sure it's not me installing the drivers wrong... ...which is a pain because I was pretty sure I'd found and fixed all of my hardware mistakes. I hope the issue is just the current prototype isn't working as a result of over-patching as it's got a fair bit of Kynar on it. Or, maybe I've got a bad IC or two... more stuff I'm waiting on! Another post with more details shortly in the hope some kind soul can tell me what's wrong.