TMS9918 video card

[J.B. Langston]

After I finish my AVR BootIO device my next project is going to be a TMS9918-based video card.  I got bored with working on the BootIO card for a while so I took a break to lay out the PCB for this.  The kicad files are here: https://github.com/jblang/rc9918.  I've attached PDF schematics and images of the PCB layout and 3D render from KiCad. Disclaimer: this is completely untested; hasn't even been breadboarded yet.  I need to make a Mouser order for several of the components before I can do that.

I followed the circuit design for interfacing the TMS9918 with SRAM in this doc: https://retrobrewcomputers.org/n8vem-pbwiki-archive/0/35845334/48860720/33053543/SRAM%20Replacement%20for%20TMS99x8%20VRAM.pdf.

[David Lee]

Very cool! I've been wondering what it would take to get real graphics on the rc2014. Never considered looking to see if retrobrew had a guide on it. This looks very promising.

[David Lee]

Just noticed your current layout has the composite connector towards the front of the board. Other cards put it on the rear. For example: https://www.tindie.com/products/maccasoft/vga-serial-terminal-for-rc2014/?pt=ac_prod_search

[Thomas Jager]

I've been hoping to find something like this, looks very good. It'll be cool to have proper graphics.

[TonyD]

Cool project. I remember checking out a Steve Ciarcia TMS9918 project for the Apple II back in the 80's.

http://www.classiccmp.org/cini/pdf/byte/Hi-Res%20Graphics%20TMS9918%20BYTE%200882.pdf.pdf

- Tony

[Spencer Owen]

That looks great! Looking forward to seeing it in action.

How do you plan to drive it?  The main thing that has held me back from making a video card is the software side of things.  I can imagine that updating either BASIC or CP/M to address this card would be quite an undertaking - at least for me it would be!  I'm sure it's going to work great though :)

Cheers

Spencer

On 6 February 2018 at 01:18, J.B. Langston <jb.la...@gmail.com> wrote:

After I finish my AVR BootIO device my next project is going to be a TMS9918-based video card.  I got bored with working on the BootIO card for a while so I took a break to lay out the PCB for this.  The kicad files are here: https://github.com/jblang/rc9918.  I've attached PDF schematics and images of the PCB layout and 3D render from KiCad. Disclaimer: this is completely untested; hasn't even been breadboarded yet.  I need to make a Mouser order for several of the components before I can do that.

I followed the circuit design for interfacing the TMS9918 with SRAM in this doc: https://retrobrewcomputers.org/n8vem-pbwiki-archive/0/35845334/48860720/33053543/SRAM%20Replacement%20for%20TMS99x8%20VRAM.pdf.

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+unsubscribe@googlegroups.com.
To post to this group, send email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/5bcdeaac-a81e-40d9-8a38-8d05810e71bc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[J.B. Langston]

To be honest, I haven't really thought that far ahead. At this point, it was just a fun diversion to see if I can do it, and an excuse to design a another PCB. Now that I've learned how, I quite like PCB layout. Something about it is strangely soothing. I guess it lets me indulge my OCD tendencies... or maybe it's like making a mandala if you prefer to put a positive spin on it ;).  

At the start, I envision this as an auxiliary display with primary I/O still running over serial.  I have little Commodore monitor I can put on my desk next to my main display to output graphics on while I interact via a terminal on my PC. I think I prefer that arrangement anyway; I've become too attached to copy and paste.

The TMS9918 manual has a few example programs written in TMS9900 assembly language. Probably the first thing I'll do is try to port that to Z80 assembly as a proof of concept.  Beyond that, I've mapped the ports to the 90-9F range so that they should line up with those on the original MSX (98 and 99). I'm hoping that at least the graphics routines from old MSX software should run without modification. However, you'd probably have to heavily modify other parts of the software to get it fully working.

Getting CP/M to display text on it could be as simple as replacing the console output function in the BIOS with one that pokes the appropriate ports.  To implement a simple dumb terminal I think you'd just need a row and column counter to keep track of where the next character goes. I haven't read enough yet to see if the TMS9918 provides any facility for scrolling the text or if you'd have to do that all in software. For input, you'd have to also build a PS/2 interface for a keyboard and write code to drive that.  That's something that my AVR could handle but it would require another I/O expander since I've already used every single pin on it for something. Alternatively for those that want to keep it old school, I've seen a PS/2 interface created from the synchronous serial port on the VIA chip. It might be possible to do something similar with the second port on the SIO/2 but I think the necessary clock pins might not be broken out on your board.

Providing graphics routines for BASIC would be a lot more work. But hey, the Commodore 64 didn't give you the ability to do anything beyond print text and change the foreground color without resorting to peeks and pokes, so at least I'd be in good company.

[Jac Goudsmit]

Didn't this chip (or a similar one) get used in MSX computers?

I think it would be interesting to have an MSX compatible RC2014. There should be plenty of software...

===Jac

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/873d7bdd-fe45-4430-bf16-6a42c162d243%40googlegroups.com.

[J.B. Langston]

Yes, it was used in the original MSX. The later MSX had an enhanced version called the Yamaha V9938 so software written for the later chip probably isn't compatible.

[J.B. Langston]

David, regarding front vs back, it wasn't really clear which was which. I used the skinny end because that is towards the back if the screen printing on the backplane is rightside up.  If the consensus is that the wide end should be the back, it shouldn't be too hard to change the layout to accommodate. 

[Wayne Warthen]

On Tuesday, February 6, 2018 at 2:18:55 AM UTC-10, Spencer Owen wrote:

That looks great! Looking forward to seeing it in action.

How do you plan to drive it?  The main thing that has held me back from making a video card is the software side of things.  I can imagine that updating either BASIC or CP/M to address this card would be quite an undertaking - at least for me it would be!  I'm sure it's going to work great though :)

RomWBW has substantial support for the TMS9918.  If a system is able to run RomWBW (has a Scott Baker 512KB RAM/ROM module), it is probably trivial to configure RomWBW to this new module (mostly I/O port changes).  Otherwise, the code in RomWBW could potentially be a base for new code in the standard RC2014 CP/M (I assume).

-Wayne

[J.B. Langston]

Do you happen to know what ports it uses for the TMS9918, or where I could find out?

[Wayne Warthen]

You will want to take a look at the TMS9918 driver source file in the RomWBW distribution.  The name of the specific source file is tms.asm in the HBIOS directory (which is under the Source directory).  There are two equates at the top of the driver source that set the two relevant port numbers.  At present, the read/write data port is $18 and the register selection/status port is $19.  However, changing the port values is a two line change.

If you wish to build a version of RomWBW with the TMS driver included for the RC2014 platform, there are a few more configuration tweaks that will be required.  They may be obvious, but if not, just let me know.

Thanks,

Wayne

--

You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+unsubscribe@googlegroups.com.
To post to this group, send email to rc201...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/720b7c5c-c893-42e4-9a27-37e6b0a297e1%40googlegroups.com.

[J.B. Langston]

I've updated the PCB layout to put the video connector on the other end. I also added copper pours and significantly reduced the via count.  The changes have been pushed to github and images are attached.

On Monday, February 5, 2018 at 7:18:06 PM UTC-6, J.B. Langston wrote:

[Ed Brindley]

Hi JB,

Nice work, design looks good :)

Very nit-picky comment - C9 should be near U5 rather than U4, and U4 doesn't appear to have a bypass cap?

Have you got a source for TMS9918s? I see there are a few on eBay but that's all I've found so far.

Cheers,

Ed

[Mike Strange]

I have taken a punt on this one - eBay item 262649909655 for the TMS9918 and, from the same people, this 252043639752 for the HM62256BLP-7 (that's for 5 off). I can see from the feedback that not all have been happy but at those prices at those prices worth a shot.

Mike

On Wednesday, 7 February 2018 11:04:47 UTC, Ed Brindley wrote:

<SNIP>

[Ed Brindley]

Thanks.

It looks like the footprint on the PCB is too narrow for the HM62256BLP-7 in that case - it appears to be a 0.6" width package :)

Cheers,

Ed

[J.B. Langston]

Thanks!

I'm not sure what you mean about the bypass cap. C9 is right next to U5 and connected across it's VCC and GND pins.  C5 is the bypass cap for U4.  The bypass cap for each of the '574s is in the upper left corner of the respective chip, with traces going to VCC and GND on the respective chip.

For the TMS9918s, I just ordered two off of eBay--they cost me about $10 each including shipping.  There were some in China for considerably cheaper but I was wary of those after reading about fake chips from China so I opted to pay a bit more for the ones I found in the US.  I haven't tested them yet--hopefully they work.

On the HM62256BLP-7, the chip I actually plan to use is the UM61M256K-15. I've got 8 of them that I pulled off of an old Pentium motherboard.  These are narrow DIP-28s but KiCad doesn't have them in its library.  I was being lazy and picked the other model after verifying that the pinout was the same.  It didn't occur to me that the footprint might be different.  I will change the model number on the chip.  Mike, I'm sorry you ordered based on incorrect information.  I guess it should be possible to modify the layout to accomodate the other chip. U2 could be rotated and moved to the left side and all of the 574s could be nudged down.

[J.B. Langston]

Sorry, I got the references backward.  C5 is for U5 and C9 is for U4.  But the point still remains that both caps are right next to the respective chips and connected directly across their VCC and GND, as close to half way between the terminals as I could get.

[J.B. Langston]

You got me thinking about this and I guess I should explain why I placed the caps where I did.  I've seen people stating you should place the bypass cap as close to the VCC pin as possible but since electrons flow opposite to conventional current that doesn't seem right.  I guess what you're actually bypassing is the AC caused by power draw so really the current would be flowing in both directions.  Ideally I would think the cap should be as close to both pins as possible but the placement of VCC and GND on opposite corners of most logic chips makes that impossible. I've never understood why they did that.  My understanding is what you're trying to minimize is inductance in the wires, but I'm not sure if having one lead shorter than the other would be preferable to having them both be an equal length from both pins. It should still be roughly the same length of wire in total. In any case there are the bond wires inside the package to consider too, which have to come from opposite corners to the center, so stressing over the exact placement of the cap too much is probably futile. I guess I should just go with conventional wisdom and put it near VCC so I don't confuse people.

[Ed Brindley]

Hi,

Yes, I have to admit I've just blindly followed the standard advice of putting bypass caps between the ground plane and VCC as close as possible to the supply pin as possible, without thinking too much about the underlying physics!

Footprint makes sense for the UM61M256K-15. :)

Just thinking out loud here, but would it be possible to use the same type of SRAM as used for main memory on the RC2014? I can't remember the exact part numbers (I think they may be AS6C62256-55PCN), but they're available new from Alliance who make loads of "legacy style" memory. (I have quite a few of these in the parts bin :D)

Cheers,

Ed

[J.B. Langston]

I'd have to reread the doc about interfacing the TMS9918 to SRAM and both datasheets again to be sure that the Alliance memories are sufficiently speedy, but IIRC, they were.

[J.B. Langston]

And unfortunately my board doesn't have much of a ground plane around those latches. I did a ground pour but there are too many address lines going everywhere for it to make it into that area.

[Mike Strange]

The reason for the bypass capacitors at one per device is to filter out the transient spikes of current caused by fast rise and fall times; these became very much worse with 74S devices.

This was just one of the reasons for multi-layer boards with 0V and 5V ground-planes; a swine to de-solder components from but brilliant at minimising inductance.

Mike

---

Date sent:                   Wed, 7 Feb 2018 07:39:09 -0800 (PST)

From:                         "J.B. Langston" <jb.la...@gmail.com>

To:                            RC2014-Z80 <rc201...@googlegroups.com>

Subject:                     [rc2014-z80] Re: TMS9918 video card

Send reply to:             rc201...@googlegroups.com

You got me thinking about this and I guess I should explain why I placed the caps where I did.  I've seen people stating you should place the bypass cap as close to the VCC pin as possible but since electrons flow opposite to conventional current that doesn't seem right  I guess what you're actually bypassing is the AC caused by power draw so really the current would be flowing in both directions.  Ideally I would think the cap should be as close to both pins as possible but the placement of VCC and GND on opposite corners of most logic chips makes that impossible. I've never understood why they did that.  My understanding is what you're trying to minimize is inductance in the wires, but I'm not sure if having one lead shorter than the other would be preferable to having them both be an equal length from both pins. It should still be roughly the same length of wire in total. In any case there are the bond wires inside the package to consider too, which have to come from opposite corners to the center, so stressing over the exact placement of the cap too much is probably futile. I guess I should just go with conventional wisdom and put it near VCC so I don't confuse people.

--
You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/0m0kbzIJ3tw/unsubscribe .
To unsubscribe from this group and all its topics, send an email to rc2014-z80+...@googlegroups.com.

To post to this group, send email to

rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/bbf9a70a-8b4d-47e7-bc59-1f13b0a936e5%40googlegroups.com .
For more options, visit https://groups.google.com/d/optout.

  

Virus-free. www.avg.com

 

[J.B. Langston]

I played around a little bit to see what it would take to accomodate the wider SRAM and it completely wrecks my layout.  If either of you wants to try your hand at modifying my layout to make it work, have at it. I'll happily check an alternate PCB layout into the github repo. Personally I'm probably going to stick with the skinny SRAM for any boards I build for myself.

On Wednesday, February 7, 2018 at 11:25:26 AM UTC-6, Mike Strange wrote:

The reason for the bypass capacitors at one per device is to filter out the transient spikes of current caused by fast rise and fall times; these became very much worse with 74S devices.

This was just one of the reasons for multi-layer boards with 0V and 5V ground-planes; a swine to de-solder components from but brilliant at minimising inductance.

Mike

---

Date sent:                   Wed, 7 Feb 2018 07:39:09 -0800 (PST)

From:                         "J.B. Langston" <jb.la...@gmail.com>

To:                            RC2014-Z80 <rc201...@googlegroups.com>

Subject:                     [rc2014-z80] Re: TMS9918 video card

Send reply to:             rc2014-z80@googlegroups.com

You got me thinking about this and I guess I should explain why I placed the caps where I did.  I've seen people stating you should place the bypass cap as close to the VCC pin as possible but since electrons flow opposite to conventional current that doesn't seem right  I guess what you're actually bypassing is the AC caused by power draw so really the current would be flowing in both directions.  Ideally I would think the cap should be as close to both pins as possible but the placement of VCC and GND on opposite corners of most logic chips makes that impossible. I've never understood why they did that.  My understanding is what you're trying to minimize is inductance in the wires, but I'm not sure if having one lead shorter than the other would be preferable to having them both be an equal length from both pins. It should still be roughly the same length of wire in total. In any case there are the bond wires inside the package to consider too, which have to come from opposite corners to the center, so stressing over the exact placement of the cap too much is probably futile. I guess I should just go with conventional wisdom and put it near VCC so I don't confuse people.

On Wednesday, February 7, 2018 at 9:13:34 AM UTC-6, J.B. Langston wrote:

Sorry, I got the references backward.  C5 is for U5 and C9 is for U4.  But the point still remains that both caps are right next to the respective chips and connected directly across their VCC and GND, as close to half way between the terminals as I could get.

On Wednesday, February 7, 2018 at 9:11:38 AM UTC-6, J.B. Langston wrote:

Thanks!

I'm not sure what you mean about the bypass cap. C9 is right next to U5 and connected across it's VCC and GND pins.  C5 is the bypass cap for U4.  The bypass cap for each of the '574s is in the upper left corner of the respective chip, with traces going to VCC and GND on the respective chip.

For the TMS9918s, I just ordered two off of eBay--they cost me about $10 each including shipping.  There were some in China for considerably cheaper but I was wary of those after reading about fake chips from China so I opted to pay a bit more for the ones I found in the US.  I haven't tested them yet--hopefully they work.

On the HM62256BLP-7, the chip I actually plan to use is the UM61M256K-15. I've got 8 of them that I pulled off of an old Pentium motherboard.  These are narrow DIP-28s but KiCad doesn't have them in its library.  I was being lazy and picked the other model after verifying that the pinout was the same.  It didn't occur to me that the footprint might be different.  I will change the model number on the chip.  Mike, I'm sorry you ordered based on incorrect information.  I guess it should be possible to modify the layout to accomodate the other chip. U2 could be rotated and moved to the left side and all of the 574s could be nudged down.

On Wednesday, February 7, 2018 at 5:04:47 AM UTC-6, Ed Brindley wrote:

Hi JB,

Nice work, design looks good :)

Very nit-picky comment - C9 should be near U5 rather than U4, and U4 doesn't appear to have a bypass cap?

Have you got a source for TMS9918s? I see there are a few on eBay but that's all I've found so far.

Cheers,

Ed

On Wednesday, 7 February 2018 02:41:25 UTC, J.B. Langston wrote:

I've updated the PCB layout to put the video connector on the other end. I also added copper pours and significantly reduced the via count.  The changes have been pushed to github and images are attached.

On Monday, February 5, 2018 at 7:18:06 PM UTC-6, J.B. Langston wrote:

After I finish my AVR BootIO device my next project is going to be a TMS9918-based video card.  I got bored with working on the BootIO card for a while so I took a break to lay out the PCB for this.  The kicad files are here:  https://github.com/jblang/rc9918.  I've attached PDF schematics and images of the PCB layout and 3D render from KiCad. Disclaimer: this is completely untested; hasn't even been breadboarded yet.  I need to make a Mouser order for several of the components before I can do that.

I followed the circuit design for interfacing the TMS9918 with SRAM in this doc:  https://retrobrewcomputers.org/n8vem-pbwiki-archive/0/35845334/48860720/33053543/SRAM%20Replacement%20for%20TMS99x8%20VRAM.pdf .

--
You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/0m0kbzIJ3tw/unsubscribe

.
To unsubscribe from this group and all its topics, send an email to rc2014-z80+unsubscribe@googlegroups.com.

To post to this group, send email to

rc201...@googlegroups.com.

To view this discussion on the web, visit

https://groups.google.com/d/msgid/rc2014-z80/bbf9a70a-8b4d-47e7-bc59-1f13b0a936e5%40googlegroups.com .
For more options, visit https://groups.google.com/d/optout.

  

Virus-free. www.avg.com

 

[mjstrange]

Not a problem, they are bound to come in some time. I will probably just knock it up on some Vero perf board anyway.

Mike 

Sent from my Samsung device

To unsubscribe from this group and all its topics, send an email to rc2014-z80+...@googlegroups.com.

To post to this group, send email to rc201...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/96e44f58-0549-4153-b326-54f9ecd94632%40googlegroups.com.

[Ed Brindley]

Hi JB,

I rearranged the ICs as a quick test and just about got it to fit - it's a tight squeeze though - see attached pic. Thinking some things are too close, especially if one was to use IC sockets.

I used Freerouter (heresy I know) so excuse any weird trace angles etc :D I will have another go and route it properly if it works on breadboard.

Another thing I thought of, ideally the M1 line should be included in the address decoding, otherwise strange things may happen when you start using interrupts. If you search this group there are some posts from (I think) Ben Chong and PianoMatt talking about it.

Cheers,
Ed

[Jac Goudsmit]

If you would put the decouple caps inside the sockets or above the top of the '574 ICs, you can move U2, U7, U6 and U5 all the way against each other and free up lots of horizontal space for U3.

--

You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+unsubscribe@googlegroups.com.

To post to this group, send email to rc201...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/71445378-07a6-400c-bb96-6114a135b123%40googlegroups.com.

[J.B. Langston]

Yeah, so it turns out I'm not very good at walking away from a challenge. I had been working on this off and on today since sending that message and I got it to work. And looks like I beat FreeRouter by 4 vias... woot! ;)

I'll update the github repo in a bit.  As far as M1... I give up. I don't see a way to do that without removing another address line from the decoder and that means sacrificing another 16 I/O ports (I'm already using 16 when I only need 2).  Next you'll have me trying to cram another IC on the board :)

[J.B. Langston]

Oh, and caps are next to VCC now, just for you Ed! :)

[Steve Cousins]

From my reading of the Z80 datasheet I believe M1 does NOT need to be included in the address decoding if RD and WR are included. 

The Z80 datasheet shows the interrupt acknowledge to be IORQ low and M1 low, but RD high. It does not show the WR signal but I think it is safe to assume WR is also high. 

Thus an interrupt acknowledge is not an I/O read (or write), but just an I/O address select. If your circuit causes a read or write when a valid I/O address is present on the bus, then you need to include M1, otherwise you do not.

A brief look at the TMS9918 datasheet appears to show all accesses require either a RD or a WR signal, so an interrupt acknowledge state will not cause a read (or write) from the TMS9918. Thus M1 does not need to be considered.

I'd be interested to know if anyone disagrees with this interpretation of the datasheet.

Steve

[J.B. Langston]

Unfortunately I'm not decoding both the read and write lines either. If IORQ is asserted without RD, then I assume a write. I did this again to avoid having to decode an additional line. Looks like I may have to try to fit another chip on the board after all.  I guess the problem is that there could be an arbitrary address on the bus during interrupt acknowledge that could trigger an unwanted read or write if it happens to fall in the decoded address range?

[Steve Cousins]

Hi JB

I've looked at your circuit and can see the problem now.

I noticed the TMS9918 has a read signal and a write signal and just assumed there would also be a chip select signal. If so there would not be a problem!

So yes, an arbitrary address on the bus during interrupt acknowledge could cause an unwanted write to the TMS9918.

The fix is only needs one more chip....

Steve

[J.B. Langston]

Phew! Well I managed to fit a quad OR gate on the board and get everything routed again... somehow I managed with even fewer vias this time!  The I/O address is now fully decoded and uses only to ports 98 and 99, and it takes both RD and WR into account.  Updated PCB and schematic has been checked into github: https://github.com/jblang/rc9918

(Reposted because I attached the wrong pictures last time.)

[A A]

On Tuesday, February 6, 2018 at 10:59:43 AM UTC-7, Wayne Warthen wrote:

RomWBW has substantial support for the TMS9918.  If a system is able to run RomWBW (has a Scott Baker 512KB RAM/ROM module), it is probably trivial to configure RomWBW to this new module (mostly I/O port changes).  Otherwise, the code in RomWBW could potentially be a base for new code in the standard RC2014 CP/M (I assume).

Outside of cpm there is also support in z88dk from C.  It's mainly aimed at the 9918 variant in the sega master system but it shows what is possible.  This is a game written in C using the devkitSMS 9918+ library incorporated into the compiler:

https://www.youtube.com/watch?v=fl1NyV_Ui7o

 In addition to this there are standard text terminals stdin,stdout,stderr already implemented (although the sms has no common keyboard so stdin is omitted).

[Ed Brindley]

Great work fitting in another component!

After consulting a few books I agree with Steve's assessment that you don't need M1 if you use WR and RD. I checked Gaonkar and none of the I/O interfacing examples use M1...

Cheers,

Ed

[Ed Brindley]

Another really minor point (I'll shut up after this!) you've got some rogue silk screen on the back of the board, and some of the component references on the front are outside the edge cuts/ under other components.

Keep us posted on how it works out on breadboard... I've got a TMS9918 on it's way from China now too :)

Cheers,

Ed

[J.B. Langston]

Oh yeah, the pins from the original template? I had forgotten about those. I'll take them off. The other thing I need to do is put in a footprint for a proper RCA connector. I had been using a barrel jack as a stand-in because I couldn't find one in KiCad's library.  Anyone know where I can find one?

[J.B. Langston]

I figured out how to make a footprint for the connector I decided to use (KLPX-0848A-2-Y), and I've updated the github repo with it.  Silkscreen is also fixed.  I've placed my Mouser order so should be able to breadboard the circuit when it arrives. After that I'll finally get this thing built. Suggestions for fabrication services? OSH Park seems to be well regarded but a bit expensive... any others I should consider/avoid?

[Ed Brindley]

Take a look at https://pcbshopper.com/

Personally I like allpcb. They aren't the cheapest of the Chinese manufacturers, but are pretty speedy, you can track the progress of the boards manufacture and the quality is good.

I think Spencer uses Elecrow, and others have recommended EasyEDA and DirtyPCBs in the past. (DirtyPCBs seems to be particularly cost effective with larger board sizes)

Unfortunately it's the Chinese Spring Festival now; most of the Chinese factories are on holiday until around the 23rd Feb so OSHPark might be your best bet!

Cheers,

Ed

[J.B. Langston]

Well, I'm finally getting back to this project after many months.  I spent this afternoon bread boarding the circuit I used on my PCB design.  I've got it hooked up to the RC2014 and a Commodore NTSC monitor. When I turn it on, it outputs... something recognizable to the monitor as NTSC video.  I don't have any code written to initialize it yet, so I'm hoping this is normal output for a non-initialized board.  Will report back again once I get some code written for the thing.  Pics attached.

[Mark T]

Where did you get the crystal? I could only find the larger package size for the correct frequency.

[J.B. Langston]

Mouser--https://www.mouser.com/ProductDetail/449-LFXTAL029962REEL?r=449-LFXTAL029962REEL

[J.B. Langston]

It's ALIVE!

[J.B. Langston]

Got it fully working now...

[Jay Cotton]

cool.  will work on lcd monitor.   should, but checking anyway.  I don't have access to a glass screen anymore.

jc

On Sunday, June 10, 2018 at 1:46:55 PM UTC-7, J.B. Langston wrote:

Got it fully working now...

[J.B. Langston]

Yes, I tried it on a Panasonic 32" LCD TV, and it works fine. Has the standard NTSC artifacting, but text is legible.

[Olaf Dannath]

Well done! I must have one of this boards. 

[Randy Mongenel]

This is a pretty cool idea. Might give me something to do with the TMS9958 chip I got in a bulk z80 chip lot. It's not a huge leap to have an early 80's style Z80 console in an RC2014.

--

You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+unsubscribe@googlegroups.com.

To post to this group, send email to rc201...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/530929ff-65c3-462e-ac20-8fe05a17eac5%40googlegroups.com.

[J.B. Langston]

I got a Mandelbrot generator working on the TMS9918.  There are still some bugs to work out in my rendering code (as can be seen from various glitches on the screen).  Rendering a high-resolution bitmap on the TMS9918 is not straightforward. The bitmap screen is not organized linearly, and you can only choose two colors per 8x1 pixel strip.  My renderer tries to choose colors in a way to minimize the color clash and emphasize the boundaries of the set. I have some way to go in achieving that goal. There is also some inexplicable artifacting that goes beyond just the expected color clash.  I have posted the code here: https://gist.github.com/jblang/2fe54044a9a71b7fd17d8f8d4c123fb5. I will update it once I get the bugs worked out.

[J.B. Langston]

I've gotten the bugs worked out of the rendering algorithm.  The corrected code has been updated at the same Gist location.  There is still some unavoidable color clash due to the limitations of the TMS9918 but this is about as good as it gets without a much more complicated color selection algorithm.

There is also occasional random noise that shows up within the set itself. I have determined that these are hardware glitches, caused, I suspect, by noise being induced on the data/address lines that I have running between the RC2014 bus and the breadboard. They appear different places each run, and I can make them worse or better by fiddling with the wires. Noise on the data lines cause the random blue stripes, and noise on the address lines cause random stripes to appear elsewhere in the part of the screen that has not been rendered yet.  I've attached a couple of examples, as well as one run that I got to render cleanly after several attempts. I am hoping that this will not be a problem once I have the chip on an actual PCB.

[J.B. Langston]

PCBs ordered. Fingers crossed!

[J.B. Langston]

More fun with the TMS.  I found a program that will convert photos to a format that can be loaded directly into the TMS9918A's VRAM: http://www.harmlesslion.com/cgi-bin/onesoft.cgi?2

I added a command to z80ctrl called tmslbin which will load a binary file to a specified address. Here's an sampling of some of the images I was able to get it to display.

[J.B. Langston]

I've got the TMS9918+z80ctrl running an unmodified MSX demo: https://www.youtube.com/watch?v=CIIRPGlvCoU

[Randy Mongenel]

That's really awesome!

Long live the Z80 demoscene :)

On Tue, Jun 19, 2018 at 7:03 AM, J.B. Langston <jb.la...@gmail.com> wrote:

I've got the TMS9918+z80ctrl running an unmodified MSX demo: https://www.youtube.com/watch?v=CIIRPGlvCoU

--

You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+unsubscribe@googlegroups.com.
To post to this group, send email to rc201...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/2028b8f4-4668-4e64-8811-4295cc492775%40googlegroups.com.

[Scott Lawrence]

Love this! :D

(is the only interface to the TMS9918 IO read/writes to ports 0x98(ram) and 0x99(register)?

On Tue, Jun 19, 2018 at 11:09 AM Randy Mongenel <mong...@gmail.com> wrote:

That's really awesome!

Long live the Z80 demoscene :)

On Tue, Jun 19, 2018 at 7:03 AM, J.B. Langston <jb.la...@gmail.com> wrote:

I've got the TMS9918+z80ctrl running an unmodified MSX demo: https://www.youtube.com/watch?v=CIIRPGlvCoU

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.

To post to this group, send email to rc201...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/2028b8f4-4668-4e64-8811-4295cc492775%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.

To post to this group, send email to rc201...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/CAB4PTAL3vjFXAbyMoM8eSOttxyV9GxV5Fve4Q%3Du%3DGzMOp5WqgA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Scott Lawrence
yor...@gmail.com

[J.B. Langston]

Yes, that's it.

You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/0m0kbzIJ3tw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rc2014-z80+...@googlegroups.com.

To post to this group, send email to rc201...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/CAKD5ztZ1y77TrjPhrjaFeRkOHyKWRU55bxMGAsyArLxyYKqJvg%40mail.gmail.com.

[Scott Lawrence]

Wow. That’s pretty awesome!  Doesn’t get in the way of the memory map of the system. I should shove my TI 99/4a onto my RC’s bus... ;)

Sent from your iPhone.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/CAMwROAyyEfGQdWfBzgPARNNg1KfkEmSYCzhdfTbmP1A8dGf8zA%40mail.gmail.com.

[J.B. Langston]

The PCB is here, built, and works great! Here are some pics, and a new video of it running the Bold MSX demo 100% glitch free: https://www.youtube.com/watch?v=1K_cc8wFURc

There are more pics on my hackday page: https://hackaday.io/project/159057-rc9918

[Eric Matecki]

Awesome !

How can I get one ?

[Mariano Cividino]

I'm also interested.

Thanks.

--

You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To post to this group, send email to rc201...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/6f5510d7-bc4b-415e-aabc-7dca359faa1f%40googlegroups.com.

[Colin Little]

Truly amazing and looks great, now it's Rev3 z80ctrl and video pcb. - will I ever get a summer hol?!!!

[J.B. Langston]

Thanks to everyone who has expressed interest. I really haven't planned on selling these directly. I don't think the amount of money I would make is worth the tax headache it would cause.  I only ordered a few boards this time since they were untested, so I don't really have any to spare. Maybe everyone who is interested can get together and share an order. I will share the design on OSH park and I also can post the Gerber files on Hackaday so that it's easier to order from places other than OSH Park.   If nothing else works out then eventually I may consider placing another order and send out the boards at cost (including shipping).  I would rather wait until I have some other PCBs to order though because shipping was more than twice as expensive as the boards themselves.  I have some other projects in mind, including a revised sound board that has MSX-compatible ports, a z80ctrl-compatible 6502 board, and a pageable RAM-only board for RomWBW.  (The z80ctrl doesn't need a ROM and the current RAM/ROM boards are not pin-compatible with RAM in both sockets.)

[Olaf Dannath]

Great Work! I want to order a PCB, Can you put the Gerber files anywhere. I tried to create the files out of your Kicad file, but I dont get something, out, that JLCPCB could read correctly. Hopefully your file does it better.

Thanks

[J.B. Langston]

Yes, I'll put them on hackaday in a bit.

--
You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/0m0kbzIJ3tw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rc2014-z80+...@googlegroups.com.

To post to this group, send email to rc201...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/7e020466-f78f-447c-8bab-cf06d9373743%40googlegroups.com.

[J.B. Langston]

Done. These are the exact gerber files I submitted to JLCPCB so they should work.  Also added the ones for z80ctrl if you want to order them both.

I will update the docs with a complete BOM and assembly guide when I have a chance. As mentioned by someone else before, you definitely want the TMS9918A chip. The one without the A is missing a graphics mode.  The other part that is very specific is the KLPX-048A-2-Y RCA connector. Other models may not fit.  For the ferrite bead, I used a FBA04HA600VB-00, but I got a message from Mouser that it is end of life now.  I think others should work fine and actually the one I have is a tight fit for the board. The closer you can get to the footprint of a 1/4W resistor, the better it will fit. For the RAM, I have put two footprints so either a wide or skinny DIP-28 32KB RAM will work as long as the pin-out is the same, which I think was pretty standard. I have tested the circuit with both an AS6C62256, which is available on Mouser, and also a skinny 32K RAM chip I salvaged off of an old Pentium motherboard (it was used for cache).  The crystal I'm using is LFXTAL029962REEL with 16pf caps.  The logic chips are all common ones that are easy to find:  1 74HCT32, 1 74HCT04, and 3 74HCT574s and I used .1uf bypass caps on everything. The transistor is a 2N4401, but I think any NPN with similar parameters should work.

[Spencer Owen]

Looks like this card might be getting a bit more attention now, what with it being featured on Hackaday!

https://hackaday.com/2018/06/22/theres-rc2014-life-in-the-tms9918a-display-chip-yet/

Good work J.B. :-)

Spencer 

You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.

To post to this group, send email to rc201...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/CAMwROAxTM%2BqvqkictQ1b3z7KMG%3DSrp7tRjB0aqTzVGz7y56z2w%40mail.gmail.com.

[Colin Little]

Thanks JB, ordered both ok. Look forward to the build............

To unsubscribe from this group and all its topics, send an email to rc2014-z80+unsubscribe@googlegroups.com.

[J.B. Langston]

I have added the BOM to the readme on github: https://github.com/jblang/rc9918. Heads up: I had a typo in the part number I gave for the RCA connector in my previous email. The part number in the BOM on github is correct.

[Michael Kamprath]

This is great! I've ordered the boards and look forward to the build, and then trying to write a game or two. 

If anyone is interested, I had a number of this board's parts on stock (like the TMS9918A from my TI 99/4a activities), so I can put together kits when the boards come in. I'll sell at cost. Contact me to reserve. 

Michael

[J.B. Langston]

If anyone is interested, I had a number of this board's parts on stock (like the TMS9918A from my TI 99/4a activities), so I can put together kits when the boards come in. I'll sell at cost. Contact me to reserve. 

Thanks for doing this. I'm sure it is a valuable service to people who don't want to source the parts themselves, and it's really not something I'm interested in doing myself.

I've also updated my article about running Bold on the RC2014 with much more detailed and easier-to-follow instructions: https://hackaday.io/project/159057-rc9918/log/148149-msx-demos-on-homebrew-hardware.  The instructions assume that you will be using a z80ctrl board to load the demo, as I am. It should also be possible to patch the demo files and load the demo from CP/M on a stock RC2014 with the TMS9918A card, but I will leave that as an exercise for the reader for now.  I would like to share a version of the demo that is already patched to support sound on the current version Ed Bridnley's current sound card, but don't want to do that without the author's permission. I have contacted Daniel Vik (one of the demo's authors) via LinkedIn and asked him if he objects to this. When and if he responds, I will upload a modified version to Hackaday.

[Michael Kamprath]

On Sunday, June 24, 2018 at 6:28:59 PM UTC-7, J.B. Langston wrote:

If anyone is interested, I had a number of this board's parts on stock (like the TMS9918A from my TI 99/4a activities), so I can put together kits when the boards come in. I'll sell at cost. Contact me to reserve. 

Thanks for doing this. I'm sure it is a valuable service to people who don't want to source the parts themselves, and it's really not something I'm interested in doing myself.

No problem ... I want the board myself.

For interested parties: I have priced the kit (between on hand inventory and that I had to order, like the PCBs), and  complete kit for the TMS 9918A board will come to $16 plus shipping (typically, $8 for USPS priority). It will be a few weeks before all the parts are in, but do contact me directly if you want one. I will have enough parts to make 10 kits, and I have a few people already on the list (beyond myself). 

Michael 

[Mariano Cividino]

Hi,

If you share the desiggn in OSH Park, that is fine for me. I can order from there.

Thanks for your work.

--

You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.

To post to this group, send email to rc201...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/6b75a596-182b-4f9c-948c-40b8d5d40cc4%40googlegroups.com.

[J.B. Langston]

Design has been shared here: https://oshpark.com/projects/KfwMvnwH

You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/0m0kbzIJ3tw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rc2014-z80+...@googlegroups.com.

To post to this group, send email to rc201...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/c4634d93-c9cb-b2d9-8bb1-59127e614b42%40gmail.com.

[mjstrange]

You say "This board is based on a circuit described by Tom LeMense"; please advise if your final board design is exactly as per the circuit or have you made any design changes we should be aware of if wanting to replicate in a different form.

Thank you.

Sent from my Samsung Galaxy smartphone.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/CAMwROAzBi5NRQcKpeGmuAHMmSajzvsaOfMT6AadKJaEQZ4kY8A%40mail.gmail.com.

[J.B. Langston]

I added the address decoding using the 74HCT138 and 74HCT32 chips. The rest of the circuit is the same.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/5b323f08.1c69fb81.4a6fb.655dSMTPIN_ADDED_BROKEN%40gmr-mx.google.com.

[Mariano Cividino]

Thanls Sir

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/CAMwROAzBi5NRQcKpeGmuAHMmSajzvsaOfMT6AadKJaEQZ4kY8A%40mail.gmail.com.

[Mike Strange]

That's great butI would really appreciate it if you would kindly share the complete circuit diagram to ensure I get it exactly the same as your PCB.

Regards

Mike

To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+unsubscribe@googlegroups.com.

To post to this group, send email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/6b75a596-182b-4f9c-948c-40b8d5d40cc4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/0m0kbzIJ3tw/unsubscribe.

To unsubscribe from this group and all its topics, send an email to rc2014-z80+unsubscribe@googlegroups.com.

To post to this group, send email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/c4634d93-c9cb-b2d9-8bb1-59127e614b42%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/0m0kbzIJ3tw/unsubscribe.

To unsubscribe from this group and all its topics, send an email to rc2014-z80+unsubscribe@googlegroups.com.

To post to this group, send email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/CAMwROAzBi5NRQcKpeGmuAHMmSajzvsaOfMT6AadKJaEQZ4kY8A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/0m0kbzIJ3tw/unsubscribe.

To unsubscribe from this group and all its topics, send an email to rc2014-z80+unsubscribe@googlegroups.com.

[J.B. Langston]

It's already on github.

To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.

To post to this group, send email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/6b75a596-182b-4f9c-948c-40b8d5d40cc4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/0m0kbzIJ3tw/unsubscribe.

To unsubscribe from this group and all its topics, send an email to rc2014-z80+...@googlegroups.com.

To post to this group, send email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/c4634d93-c9cb-b2d9-8bb1-59127e614b42%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/0m0kbzIJ3tw/unsubscribe.

To unsubscribe from this group and all its topics, send an email to rc2014-z80+...@googlegroups.com.

To post to this group, send email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/CAMwROAzBi5NRQcKpeGmuAHMmSajzvsaOfMT6AadKJaEQZ4kY8A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/0m0kbzIJ3tw/unsubscribe.

To unsubscribe from this group and all its topics, send an email to rc2014-z80+...@googlegroups.com.

To post to this group, send email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/5b323f08.1c69fb81.4a6fb.655dSMTPIN_ADDED_BROKEN%40gmr-mx.google.com.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/0m0kbzIJ3tw/unsubscribe.

To unsubscribe from this group and all its topics, send an email to rc2014-z80+...@googlegroups.com.

To post to this group, send email to rc201...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/d97802c4-e460-4d1b-b4c0-3fba47152d1e%40googlegroups.com.

[Mike Strange]

Thanks, found it.

To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+unsubscribe@googlegroups.com.

To post to this group, send email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/6b75a596-182b-4f9c-948c-40b8d5d40cc4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/0m0kbzIJ3tw/unsubscribe.

To unsubscribe from this group and all its topics, send an email to rc2014-z80+unsubscribe@googlegroups.com.

To post to this group, send email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/c4634d93-c9cb-b2d9-8bb1-59127e614b42%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/0m0kbzIJ3tw/unsubscribe.

To unsubscribe from this group and all its topics, send an email to rc2014-z80+unsubscribe@googlegroups.com.

To post to this group, send email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/CAMwROAzBi5NRQcKpeGmuAHMmSajzvsaOfMT6AadKJaEQZ4kY8A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/0m0kbzIJ3tw/unsubscribe.

To unsubscribe from this group and all its topics, send an email to rc2014-z80+unsubscribe@googlegroups.com.

To post to this group, send email to rc201...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/5b323f08.1c69fb81.4a6fb.655dSMTPIN_ADDED_BROKEN%40gmr-mx.google.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/0m0kbzIJ3tw/unsubscribe.

To unsubscribe from this group and all its topics, send an email to rc2014-z80+unsubscribe@googlegroups.com.

[Michael Kamprath]

In case people aren't aware, there is a pin compatible TMS9918A replacement that has modern video outputs:

http://codehackcreate.com/archives/592

I have one of the original Mk 1 models I intend to try out in J.B.'s TMS9918A RC2014 board, and I have put myself on the wait list for the Mk 2 model (which has HDMI out). 

Michael 

[Mark T]

I looked at the F18A quite a few times but it didn't seem like it was still active. Good to see a MK2 might be available soon. I thought the MK1 might need the DIL socket on my pcb rotating but the MK2 looks like it would be a drop in.

I think I also saw VHDL for an FPGA on one of the MSX forums but couldn't find it again just now.

[J.B. Langston]

I looked at the F18A quite a few times but it didn't seem like it was still active. Good to see a MK2 might be available soon. I thought the MK1 might need the DIL socket on my pcb rotating but the MK2 looks like it would be a drop in.

 I will be interested to see if this works with my board. I think that the F18A has its own RAM onboard, so it might be possible to omit the RAM, 74HCT04, and 74HCT574 chips from my board.

[J.B. Langston]

FYI, I have confirmed that Bold will run from CP/M as well as z80ctrl.  I have attached a zip file to the project that includes the modified version of Bold that uses the default YM/AY sound card ports of D0 and D8.  It also includes a README with instructions and scripts for launching bold from z80ctrl or CP/M.

https://hackaday.io/project/159057-rc9918/files

[J.B. Langston]

Look what I'm working on...

[Colin Little]

Oh no!! We'll have to wait years now for any hardware updates   :(

Actually, looks really exciting :)

[Thomas Jager]

Ordered and built a board, though the video output was all pixels (more like a grid), with darker grey on the left 1/5th or so while running the Mandelbrot example. Guess I've got some debugging to do...

[J.B. Langston]

Can you take a picture?

What assembler did you use, and how are you running it? 

What clock speed are you running?

On Tue, Jul 3, 2018 at 10:21 PM Thomas Jager <tho...@thomasjager.ca> wrote:

Ordered and built a board, though the video output was all pixels (more like a grid), with darker grey on the left 1/5th or so while running the Mandelbrot example. Guess I've got some debugging to do...

--

You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/0m0kbzIJ3tw/unsubscribe.

To unsubscribe from this group and all its topics, send an email to rc2014-z80+...@googlegroups.com.

To post to this group, send email to rc201...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/3b51578d-d251-4d62-a8d6-7d0276895736%40googlegroups.com.

[Thomas Jager]

My initial description wasn't quite accurate; it was from memory, but I've attached a picture. This was done using a more modern TV, so it could be causing issues with signal tracking.

I used sjasm to assemble it, with no additional command line arguments other than the assembly file.

This is running on a Mini, with the stock 7.37 clock on that. (The only other modification is that I ran some wires from the higher address lines to give me a full 32 kB of EEPROM instead of the normal 8 at a time.

I've also got some signal integrity/ distortion/blacking out on parts of the screen issues. I also noticed that I used the 27pF caps from the schematic instead of the 16 pF caps you specify in your GitHub repo.

To be honest, I was just really happy to see anything resembling a video signal come out of it.

On Tuesday, 3 July 2018 23:24:28 UTC-4, J.B. Langston wrote:

Can you take a picture?

What assembler did you use, and how are you running it? 

What clock speed are you running?

On Tue, Jul 3, 2018 at 10:21 PM Thomas Jager <tho...@thomasjager.ca> wrote:

Ordered and built a board, though the video output was all pixels (more like a grid), with darker grey on the left 1/5th or so while running the Mandelbrot example. Guess I've got some debugging to do...

--
You received this message because you are subscribed to a topic in the Google Groups "RC2014-Z80" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rc2014-z80/0m0kbzIJ3tw/unsubscribe.

To unsubscribe from this group and all its topics, send an email to rc2014-z80+unsubscribe@googlegroups.com.

[J.B. Langston]

The caps might be the issue, depending on how sensitive the crystal is. You should use whatever value is specified on your crystal's datasheet. I used 16 pF, which was specified for the LFXTAL029962REEL crystal listed on the BOM. If you are using a different crystal, the value might be different.I believe the 22 pF value on the schematic came from the circuit I copied from Tom LeMense's article on interfacing the TMS9918A with SRAM, which was done before I selected specific parts to order.  Sorry, I will update the schematic so I don't confuse anyone else.  Are you using LFXTAL029962REEL for your crystal or some other part? If it's different, what is the exact frequency?  The TMS9918A datasheet specifies 10.738635 +/- 0.005 MHz.

Another thing I have seen cause video distortion is if the EXTVID bit gets enabled in register 0.  This would cause the TMS9918A to attempt to sync to an external composite signal that is not there.  When that is enabled, it causes the video to become severely distorted on my CRT monitor, but I haven't tried it on a LCD, so I'm not sure how it would look. I'm not sure how that would have happened though if you were using my unmodified Mandelbrot program.  Maybe check for solder bridges on your data lines to make sure D0 isn't shorted to D1 or to VCC somehow.  A 1 bit in D0 would enable external video.

I don't have any other ideas, except maybe try a different monitor, or try a different TMS9918A chip if you bought a spare.

[Thomas Jager]

What I ordered is not the same item, but it is nominally exactly that frequency, though there's nothing printed on the can, which I found unusual. I got it from Digikey, though I don't have too much faith in them this time because they messed up something else on my order. (Replaced 10x of one item with a duplicate 5x of another item, in the labelled bag for the first item) After I run through the who thing checking for shorts, I'll try swapping out the crystal caps for some 20 pF ones, which is the typical load cap in the datasheet, assuming I understand how that works.I might try swapping out that crystal if I can find another because that that pattern seems odd.

[J.B. Langston]

Do you have an oscilloscope or a multimeter that measures frequency that you could hook up across the crystal to see the frequency its outputting?  I'm not sure how accurate this will be since the capacitive  loading of the probes may also affect the frequency, but it should at least show you if it's something's crazy off.

[Mark T]

I also ordered crystals from digikey, I noticed that the crystal used by JB had esr of 40 ohm, but the HC49US size from digikey have esr of 60 ohm, so I ordered the larger size HC49/U, CTX1443-ND which has esr of 30 ohm. Although the spec is for 32pF caps I'm using 22pF and it seems to be running at the correct frequency (I can set colors for the screen background although it might need to trimming to avoid color artifacts on white).

TMS9918A spec doesn't specify esr, so I don't know what is needed, just took a guess that I should use the lower esr as I had space on my pcb.

Tuning the cap values might just be more critical on a higher esr crystal.

Mark

[Thomas Jager]

I don't have an oscilloscope fast enough for the crystal itself, but I was able to measure CLK/24 out from the TMS9918. Turns out the main clock would have been running at 6 MHz for the 250 KHz I was measuring, which is waaay off of what it should be. It seems that I was using a crystal designed for series use instead of the parallel configuration. While the capacitors would have been off the right value, the series and parallel frequencies should have been fairly close, only slightly off, so I'm not sure what's going on there.

As a side note, have you used the the equation (https://community.nxp.com/thread/388856) to calculate the appropriate values for capacitors from the load capacitance in the datasheet? If so, what stray capacitance did you estimate?

[J.B. Langston]

Hi, sorry for the delay responding. I'm glad you're making progress diagnosing the problem. I did not use any equation, I just used the value recommended in the datasheet (16pF): https://www.mouser.com/datasheet/2/741/LFXTAL029962Reel-996318.pdf

[J.B. Langston]

So after reading the link, it appears I didn't understand how to properly choose the capacitor. I assumed I was just supposed to use exactly the value stated in the datasheet.  I have no idea what the stray capacitance on my board is but the traces are fairly short and far apart so if I had to guess I'd say it's at the lower end of the 2-5pF range specified in the article.  For my crystal, that would give 2 * (16 - 2) = 28 pF.  However, I haven't noticed any problems with the 16 pF capacitors so apparently it's not that critical. 

[Thomas Jager]

I agree on it probably being on the lower end. Once I get my new crystals, and hopefully get things working, I'll probably try varying the capacitance to see if anything noticeable happens.

[J.B. Langston]

I've been working on a new revision of my board that will work with ColecoVision software out of the box.  It's basically the same BOM with the addition of more jumpers.  Based on feedback from Mark T, I have hopefully made it compatible with the Sord M5 as well.

Here's how the address decoding works:

- J4 configures address bits 7-5 which lets you select a block of 32 addresses: 00-1F (left) ... E0-FF (right). For ColecoVision, you would set this to A0-BF (6th position). For MSX, you'd set it to 80-9F (5th position).  For Sord M5, you'd set it to 00-1F (1st position).

- J6 configures address bit 4. There are 3 options: ignore (left), 1 (middle), or 0 (right). This lets you use the entire 32 address range, the upper half, or the lower half, respsectively. For ColecoVision, you would set this to ignore (left). For MSX and Sord, you would set it to 1 (middle).

- JP1 configured address bit 3. In the upper position, it must be 1. In the lower position, it is ignored.  For MSX, you would set this to the upper position. For ColecoVision or Sord, you would set it to the lower position.

- JP2 configures address bit 2 and 1. In the upper position, they must both be 0. In the lower position, they are ignored.  For MSX, you would set this to the upper position. For ColecoVision and Sord, you would set it to the lower position.

This allows configuration of the correct ranges for all 3 systems:

- MSX (88 and 89)

- ColecoVision (A0-BF, with BE and BF typically used)

- Sord (10-1F; I'm not sure what address the software typically uses)

For other Z80/TMS9918A systems, such as the SpectraVideo and MTX, it should at least be possible to configure a superset of the correct addresses, but it may not be possible to decode the addresses as precisely as the original system.  Depending on what else the system originally had mapped to these addresses, this may or may not cause a conflict. This is the best that I can do without adding any more decoding chips, which I don't have room for on the board.

I also added a jumper (JP4) to connect the TMS9918A's interrupt pin to either INT (upper) or NMI (lower) on the RC2014 bus.  I have added a extended bus pins so NMI can be connected to the bus.  ColecoVision connects the video interrupt to NMI, so this change was necessary for compatibility.  MSX, and I assume most other systems use INT.

Finally, I added a header (J7) with pins for (left to right) CPUCLK, GROMCLK, EXTVDP, and GND. This should allow the CPUCLK and GROMCLK signals to be used via jumper cables with other boards the need them, for example on the Sord M5.  It should also be possible to daisy-chain multiple TMS9918 chips using the EXTVDP signal, or to genlock an external video source. I added a GND pin to use with an external video source if needed.  

I am going to check these changes into Github now but I am waiting to design my SN76489 and Joystick interface boards before I have them manufactured.