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.

Good news! I have a working 8Mb RAM board in my ADAM. My sincere thanks for all the encouragement and most helpful advice, To recap: -A new 8Mb RAM board for the ADAM -Does not need a middle slot card for full function but can make use of one -Battery backup is an option A few piccies and a repost of the Gerbers for anyone who wants to make their own included below. As can be seen I've yet to add the batter holder - STILL waiting on parts! I've included a photo of my IDE board and the simple mod I made for easy access to the /IORQ line. PS So that's the Coleco Game Pad and memory board projects sorted, now I need to get that darn 80 column card (and it's add-ons) running and pluck up the courage to dissemble my ADAM to try my latest take on an internal AY card and I'll be happy. PPS I've got a terrible memory, for those I've been in touch with via pm please send me a reminder. ADAM_Mem_8mb_v2_BAT_77.5x56.zip

Ahh, thanks for that I shall give it a go and report back. Um, I going to reveal just how little I know about CP/M - how does the OS 'know' how and where to address the serial hardware if I haven't loaded some kind of driver?

Ok, a step closer... My ADAM wouldn't boot with the latest board ordered in place. After much faffing I did a sanity check and the machine still wouldn't boot with a wholly unpopulated board - most odd, especially as the only change I made was to fix the incorrect placements of the PWR and GND pins for a couple of IC' and the Pi header... ...schematic time - no, I did nothing else. ...careful check over the boards - I'll be blowed if I can see any mistakes or indeed manufacturing errors -Absolutely no idea- So with a sigh I grabbed one of my first run boards and carefully reworked it to fix the routing errors, rechecked everything, assembled it, plugged in a new Pi Zero, and... The very good news is the board and Pi seem to be working as far as I can tell, so time to install some drivers and see if I get an 80 column display. Um, two issues: -I thought I had the drivers for the MIB dual serial board but it seems I don't -It will be interesting to see if I can work out how to install drivers under C/PM / TDOS, being the n00b that I am. I've had a good old Google and haven't been able to turn up the drivers, can anyone help? Micro Innovations Dual Serial Board - the one that goes in the left slot. Many thanks.

Hmm, It seems I didn't include a way to flip the AVAIL bit... easy enough to sort.

I know, I've got several projects on the go and apart from the DIY gamepad none are in a working state. Soon I hope. The 80 Column board that I'm hoping is near completion (oh, I hope so!) is really a MIB dual serial clone with a Raspberry Pi tagged on to function as a serial terminal. Today's idea is a different spin on the goal of getting the ADAM to produce an 80 column display. In short you take an ATmega 328, add some glue logic, and strap it to the side port of your machine. The ATmega is programed to function as an 80 column VDP whose output I envisage being routed through the TMS9918A and so mixed with the composite out - it's rather nice that the 9918A can daisy-chain further VDP's. With this expansion in place you will have a very fast 80 column text mode with GFX characters, some bitmap capability, and limited VT100 emulation. As it happens it's mode of operation is rather in keeping with the TMS chip itself as it maintains it's own video memory (not much!) and you send it instructions to do it's job - no extra RAM gobbled up. Apart from having a fast 80 column mode I can see some interesting options with this one as it's output is mixed with the 9918A's output. Details: Currently this design lives on port BCH as I'm not aware that's used by anything else but is close to the 9918's port. It uses 10 lines: D0-D7 plus AVAIL and ACK. AVAIL = IORQ & WR & A[7..0]==BCH ACK = IORQ & RD & A[7..0]==BCH Check if the VDP is ready via ACK and if it is write your data on D0-D7 and let it know flipping AVAIL, The VDP will do the rest. You can send ASCII for text and there's a command list for other screen-related actions. The board itself is nice and simple and includes an ISP programming header for the ATmega - for those who don't know these IC's are far, far easier to program than your usual CPLDs or FPGAs so should be within easy reach of anyone that wants to build one. So what's the catch? Driver software, there isn't any. The board as-is should be perfectly functional if you are happy to 'bang the metal' with peeks and pokes but it would be so much nicer if there were proper drivers: -CP/M and TDOS of course as it's an 80 column board and hopefully supports enough VT100 Esc codes, more could be implemented via a driver if needed -A version of Smart Basic that supports it would be nice. -Driver for other uses..? Now I can't code for toffee so the drivers aren't going to come from me. Also, assuming the darn thing actually works, my other 80 column project will do me fine for what I want. But if there is any interest in this board (coders) I'll go ahead and make some for any who want a driver development system. I'm otherwise not intending to make this if there's no interest. Thoughts: -Anyone willing to code CP/M / TDOS drivers -Anyone willing to patch Smart Basic -Suggestions welcome, including the preliminary hardware decisions / mistakes I've made -I think I have the source for the ATmega side of things if anyone it thinking "I wonder what more could be squeezed out of this puppy?" PS I guess this is a bit more 'old school' than my other 80 Column project as the ATmega is functioning as a discrete GFX processor surrounded by come good old ICs... ...Yes I know; I went for a surface mount ATmega. The SMD variant is dirt cheap and more easily available than the DIP variety. Also for any who may be worried they are actually dead easy to solder once you know how - a subject I'll happily discuss if it comes up.

Hi, Thanks for your interest and perspective. Assuming these projects of mine actually, finally, work properly you'd be very welcome to a spare PCB or two - as a general rule I don't do production runs as I do this stuff for a weird form of entertainment and going in to production is far too much hassle. Having said that I'm happy to post spare PCB's on request for a very small donation to cover costs. Also, unless specifically stated otherwise, I always share my files and am happy for anyone to do their own production runs. I have to admit I tend to go for internal expansion where I can for neatness but see your point abut there being far more Colecovisions than ADAMs. I'm pretty new to the Coleco scene and I'm more than happy to be educated but sadly I don't know it this board would be any use to Colecovision owners as it's video output and USB input run over a serial connection. I suspect this board is really only useful to people who want an MIB3 or Orphanware-like video card for CP/M but can't lay their hands on on. I'm not aware of a way to route VDP output through it... ...again I'd be happy to hear to the contrary but for better VDP output with Coleco systems I believe the F18a is the only game in town - having said that from a hardware perspective it would be a trivial matter to hook up the GPIO headers of a Raspberry Pi to the expansion connector. The Pi could then serve as any expansion hardware required, driver software allowing... one could make a software-based F18a with such a set up, the advantages being extra functionality would be anybody's driver release away and it would be very much more and be within the grasp of a hobbyist to construct without much bother. This is something I really, really like to do but the coding side of such a project is absolutely beyond me - it would be fantastic if the awesome designer of the F18a would consider rewriting his set up to run on the Pi but would he have the motivation? On the software front I've tried to make sure this board is fully compatible with MIB's drivers so I'm hoping I've got that one covered. It sounds like my update to allow for piggy-back expansion on this card might prove useful - without using programmable logic there wasn't a way to squeeze in a parallel interface, and I hope such an 'expansion bus' will allow for further goodies down the line. On the hardware front I can certainly do a side-port version of this design, given I'm not sure if it would be useful to non-ADAM owners would there be any interest? Out of boredom and frustration, because my projects are languishing while I wait on components to finish them, I've done a design for an ATmega-based 80 column card I mentioned above that will plug in to the side port and will hopefully output via the 9918... I think I'll start another thread about that and see what people think.

Just out of curiosity: The above set up should hopefully work under CP/M (and TDOS?) as a colour serial terminal, with potential future options, but... There's another way to construct a simpler, and very fast, 80 column display for the ADAM that could work under any OS. Before I bought my ADAM I did a design for a Z80-based CP/M computer based on Grant Seale's design but never got round to making it. Part of the design was for a B/W 80 column display with limited GFX capability that requires no system memory to run - with hindsight I guess it's rather like the 9918A in operation. The basic idea is you need 10 lines: -D0 to D7 for passing info to the GFX processor -Avail for output -ACK for input The control cycle would consist of: Initialisation Set D0-D7 and AVAIL to be outputs. Set ACK to be an input. AVAIL can be high or low. Send to the display When ACK = AVAIL the display ready. Place character on D0-D7. Flip AVAIL to indicate data is ready to be processed... ...you're basically sending characters or control codes and Esc codes can be sent for limited VT100 compatibility. All this is achieved with an ATmega328, a 74HCT166, a crystal and a few passive components. As the system would have direct access to the VDP, and given I believe the 9918A can mix it's output, I think that would be enough for all the screen real-estate one could ask for. I'd also be very happy to roll a version GFX card that could be interfaced with the ADAM... the catch? Ideally such a board would need driver software to make best use of it, but at a pinch could be driven with a few peeks and pokes. So if there's interest, especially if someone wants to write a driver for such a device do let me know.

Well I've soldered up both my new Pi Serial board, and memory board, as far as I can... waiting on some components to finish the job and then fingerers crossed with the ongoing testing. In a fit of combined madness and frustration I redesigned the board yet again to include a port extension header, along with the addition of ROM support, So it's possible to piggy-back further expansion boards on to that. I also flipped the Pi interface on to the back of the card to allow more room for cabling and the option to use other Pi's (in the latter case the composite out won't work as only the Zero has the correct header). The header also provides an easy attachment for 'my' RAM board's flying lead. I also changed the serial headers to FTDI type and added current-limiting resistors as 'my' ports are TTL only... ...sadly the redesign was done after I ordered the current board. But you never know this one might also be a dud, in which case I'll get an opportunity to buy some more funny looking coasters. ...and in a further bout of madness I've done two piggy-back boards to get the ball rolling: -A MIB compatible Parallel interface In the end it took lots of ICs to implement so there really was no way to add directly to this card. -A SGM compatible AY Sound card Addressing logic completely redone more to my liking. Annoyingly I had to add both Power-on reset and clock circuitry because Coleco in their wisdom didn't think to add those lines to the expansion bus.., bah! The idea is you can extend the middle slot for as long as you have room, don't overload the Z80's bus, or run short of power. The latter two can be fixed with some buffering and bringing in a 5v line. So... Having still not successfully tested anything I'm doing my best to get a much egg on my face as possible. I do hope the rest of my parts turn up soon. PS Having fried my Pi Zero I ordered another only to get a message saying I have to wait a bit as you're only allowed to order one a month - blast! My other Zero is soldered in to my Beeb to masquerade as a second processor and the Zero W in my printer isn't compatible with the PiGFX software - sigh! ...I can see impatience is going to result in a nasty hack to bend a standard Pi to my will.

Ahh, a most interesting topic. I do hope there's lots of posts on this subject. For myself I'm a total CP/M n00b so there's every chance I shall be asking some very basic questions in the near future. Apologies in advance for polluting a potentially most interesting thread with daft questions. (FWIW: Plan "A" for my attempt at an 80 column card, assuming I get it to work at all, is primarily support for a colour VT100 terminal under CP/M (TDOS?). In the future I'd really, really like to get the computer-side A2Pi software ported to the ADAM... and later there's all sorts of Pi-related projects that could be leveraged for use with an ADAM. Sadly I can't code for toffee and I suspect 6502 code intended to run under the Apple II might be a bit unfunny to port to the Z80 on the ADAM. (I believe there is source code available) Sadly my card will never be a straight replacement for the 9918A, but I'd be very willing to do a Pi-ADAM (Colecovision) interface with a view to making a F18a-esque board - if anyone with the coding talent was interested in the software side.)

Yes, I guess you're right. ...in other news my latests boards came today so I hope to have better results on the project front.

Well, I've had a notification from Seeed that my latest boards have been posted so hopefully I will be able to post some more progress in a wee bit. Out of boredom I did yet another update for this board (maybe I should wait to see if I can actually get something functioning) to add ROM support for any future iterations. Some observations and questions: Observations: I kind-of see why MIB went for the serial IC they did (rather than a SIO(2) that would have made more sense to me). There's no CLK line on the middle expansion connector! That rather squashes my hopes of doing an update with a more modern, or at least more easily available IC. While perusing the GAL logic for MIB's cards to see what potentially useful extras might be worth including in a future card I noticed that while all use the same serial IC each card actually addresses it differently. I guess that means one will have to be careful which of their drivers are used with my card, currently MIB2 compatible. I wonder why..? Part of the reason for having a further look at their GAL logic was to see about possibly adding a printer port. As I'm quite deliberately doing this with standard logic it looks like a parallel port is going to be very difficult indeed given the avalanche of extra ICs required just won't fit. There's other stuff I'd like to consider but the lack of certain signals on each of the internal expansion ports will make such plans difficult if not impossible. (for me) Questions: Assuming I come up with a true multifunction card which of MIB's drivers would people prefer I aimed at? A potential option might be to include a set of jumpers so my card's serial could work with any driver set, at the cost of space on the board. I really don't see how I can find space to include parallel support if I don't use a GAL. Is there any demand for such a thing? One potential option might be to include a piggy-back header so further options can be added 'sideways'. Not neat but that will sort space issues. Both the middle and right-hand slots have unconnected pins - I'm very tempted to add lines to some of those pins to make the internal slots more generally useful. That's no issue for me but if anyone wants to use such a potential board that requires modding of their ADAM's slots is that: -Going too far? -If not what / where would people like the new lines added? ...as a minimum I'd really like to add a CLK line to J6. Preferably add enough lines to make it equivalent in function to the external slot