Jump to content
dlv

Development of Nubus graphics card outputting to HDMI?

Recommended Posts

6 hours ago, dlv said:

Which book are you referring to? It doesn't appear to be "Designing Cards and Drivers for the Macintosh Family (Second Edition)" (appendix B and C appear to be PAL listings). 

Well there's a lucky break/happy coincidence, You're looking at DCaDftMF2e from 1990 and I was looking the 1992 3e in book form. I rarely reference the PDF versions. Designing_Cards_and_Drivers_for_the_Macintosh_Family_3ed_1992 You'll find the link on this page with a great article at the bottom. IIRC the Byte article describes the trials and tribulations of NuBus development for the newly released 68020 Macintosh II, which predates introduction of the SE/30's 68030 PDS by a stretch. They would have been working from Designing_Cards_and_Drivers_for_the_Macintiosh_II_and_SE_-_1987 Haven't seen that last one before, now I've got some new reading to do.

 

If someone has and is familiar with the Inside Macintosh series, could you please check for PAL listings of the Macintosh II Video Card a/o Sample Video Card for us? With that we should have most of what would be needed to re-create the TOBY card as the basic design reference I think.

 

The three Card Design books in the NuBus architecture development series appear to be cumulative AND subtractive, with each referring back to need for an understanding of the previous editions as well as GttMFH in both editions.

fej8.jpg&key=8000789d5fa01e5f0005cf089cd

Later version:

53d4.jpg&key=d7abc4961bcff55d3b938333817

 

Those are from BMOW's stickied Hacks thread:

 

I see there have been a couple of replis posted while I was piecing this together so I'm signing off on this one at the point for a look see.

 

Edited by Trash80toHP_Mini

Share this post


Link to post
Share on other sites

YAY! Those development roadmaps hit page break discontinuity barrier just right for a change!

 

46 minutes ago, DaveyPocket said:

What might be worth trying first is to develop this idea in software - i.e. Build the design into an existing emulator such as Basilisk II then graft it over to hardware. Can definitely be useful for debugging and obtaining an understanding of how OS would interact with a video card expansion.

Fabulous! :approve: That would open development up to an insane level of collaboration.

 

59 minutes ago, Gorgonops said:

It's a different aspect ratio than 1080p so if you want something that scales naturally to 1080p it's a bad choice. It's also not a particularly common resolution for stand-alone monitors; 1280x800 and 1366x768 are both (probably) more common, although, again, they're far more likely to be found as panel sizes in cheap laptops than in monitors. Of this motley crew of also-ran resolutions 1280x800 is probably about the best to target because at least its 16:10 ratio *is* pretty common (it's a widespread small laptop/table panel size, and it also scales by 1.5 and 2.0 for 1920x1200 and 2560x1600, which are also "not rare", albeit less common than 16:9 monitors) *and* it likewise comes in at *barely* under one megapixel. (1366x768 is barely more.)

Yeah, that's what I was WAG'n and why I was trying to keep the table as simple as possible. 1280x800 looks like a winner along with 720p, I'm posting from a 1920x1200 LCD right now and you've said it's the highest resolution that Analog VGA can handle so it follows that it's the best/highest resolution interface that'll work with a VGA/ADB KVM switch for a 68k thru G4 classic OS collection.

 

Quote

So, I believe the tl;dr there is from a software standpoint a PDS video card shouldn't look much different from a Nubus one. I'm looking at the same reference you are right now, and while, yes, it doesn't specifically include an example of a PDS video card *if* you build such a card that maps to the appropriate "Pseudo-slot" addresses and includes a declaration ROM (whose contents will essentially be identical to a real Nubus declaration ROM) the same mechanisms that allow such cards to be ID'ed and used at boot time will apply.

Yeah, that's exactly right according to all docs in the series by my read and why a PDS card poses no boot display problems. As I said, PDS postdates NuBus and as I understand it, the ZORRO III is pretty much the equivalent of the 68030 I/O architecture of IIsi/SE/30 with an unnecessary (ZORRO II connector/card compatibility) multiplexing setup. Many(most?) NuBus Macs and all NuBus architecture PowerBooks follow the 68030 interface model. Miniaturization of a baseline PDS design would open the 190/5300 and 1400 video card slots to current display tech as well as a larger BlackBird PDS expansion card.

 

Edited by Trash80toHP_Mini

Share this post


Link to post
Share on other sites

edit window expired: From the prelude to the VidCard section, the greater depth of VidCard development was added because the TOBY card had been discontinued, being no longer available to developers. So your second edition Appendices A/B were shoved back to C/D in the third edition.

Share this post


Link to post
Share on other sites
12 hours ago, Gorgonops said:

Conveniently enough 1MB is also the same size as a 24 bit standard Nubus slot space, which means that there's no issue with using the card at its full (indexed) resolution regardless of whether the Mac is in 24bit or 32bit addressing mode.

 

There was either a thread about this or discussion about it in an earlier thread about video card building.  If it had its own thread, it was one I started.  I kind of remember starting a thread asking that specific question, but I could be misremembering.  IIRC, someone knowledgeable claimed there was a mechanism to handle addressing more than 1MB in a slot even with the machine in 24 bit mode.   Maybe I'll hunt for it later, hoping that the old thread is not amongst the victims of hte software transition.

 

Targeting PDS is a good idea because I doubt that a new-work card in a Nubus slot will perform any better than the old NuBus cards did no matter how whizbang the new hardware.   NuBus is really really slow.

 

However, I hear you about the 68040 cache slot.   Has anyone identified the make and model of that connector and gone looking for a supply in the wild?   I've been able to find supplies of connectors like the Cache and ROM connectors for X100 machines and the Alchemy family.    That 68040 PDS connector may be more rare.

Edited by trag

Share this post


Link to post
Share on other sites

The FPGA that replaced/is replacing the Spartan family has on-board DDR2 controllers.  They're only 16 bits wide, but I think some of those chips have four of them.   DDR2 is fast enough that with good logic, one could probably send an acknowledge to the 680x0 processor on the next cycle after any transaction.   Might have to use an internal SRAM block as a FIFO buffer because of the latency though.   Anyway, that would hit the theoretical maximum speed, absent Quickdraw acceleration.

 

The biggest challenge is finding a development board with enough IO brought out to connectors to interface with the 680x0 bus.   I don't  think there is one.    A custom board would be needed.   And someone or some service would have to solder down the multi-hundred pin BGA FPGA.

Edited by trag

Share this post


Link to post
Share on other sites
2 hours ago, Trash80toHP_Mini said:

Yeah, that's exactly right according to all docs in the series by my read and why a PDS card poses no boot display problems. As I said, PDS postdates NuBus and as I understand it, the ZORRO III is pretty much the equivalent of the 68030 I/O architecture of IIsi/SE/30 with an unnecessary (ZORRO II connector/card compatibility) multiplexing setup. Many(most?) NuBus Macs and all NuBus architecture PowerBooks follow the 68030 interface model. Miniaturization of a baseline PDS design would open the 190/5300 and 1400 video card slots to current display tech as well as a larger BlackBird PDS expansion card.

 

The Zorro II bus on the Amiga is pretty much a direct pinout of the 68000 (24-bit address bus) plus a bus arbitration chip called Buster to handle DMA. Zorro III upgraded this to 32-bits all around and expects a 68030 or 68040.

Share this post


Link to post
Share on other sites

One of the slightly interesting tidbits the "DCaDftMF" book where it contrasts the simplcity of PDS with the painful drudgery of Nubus is how it notes that when you use the 68030 PDS it lets you take advantage of the dynamic bus sizing abilities of the 68030, which makes it relatively simple (compared to Nubus, apparently) of implementing a card for said bus that's only eight or 16 bits wide. (For instance it suggests that this functionality would make it relatively trivial for a designer to make SE and SE/30 versions of the same expansion card containing an 8-bit widget on it.) Obviously if you're looking for MAX POWER you're going to want to have a 32 bit wide card but... on the flip side, if you're interested in literally porting that Amiga Zorro II-targeted card design over it should be completely possible to build a 16-bit wide video card for 68030 PDS. (Which would add up to very minimal changes.)

(For the record I'm pretty sure the VRAM built into an SE/30 is only 8 bits wide; for all practical purposes it's implemented as if it were a *really* brain-dead PDS video card, including a stub Declaration ROM.)

68040 PDS might be another kettle of fish. Doesn't the 68040 require external arbitrators to handle different-width peripherals? (I kind of thought that was one of the reasons why Apple was so much in the business of using 68040->68030 bus bridge chips in so many cheap-o desktop and Powerbook models...)
 

7 hours ago, trag said:

There was either a thread about this or discussion about it in an earlier thread about video card building.  If it had its own thread, it was one I started.  I kind of remember starting a thread asking that specific question, but I could be misremembering.  IIRC, someone knowledgeable claimed there was a mechanism to handle addressing more than 1MB in a slot even with the machine in 24 bit mode.   Maybe I'll hunt for it later, hoping that the old thread is not amongst the victims of hte software transition.

There may well be. I certainly haven't read the manual that's being bandied about here well enough to say one way or the other. All I will say is it seems to have a lot of contradictory statements about 24 vs. 32 bit mode. (In the SE/30 PDS section, for instance, there's a specific blurb about how since the SE/30 only included 24 bit Quickdraw a video card designer should factor in having to bundle a RAM-resident 32 bit Quickdraw implementation...)

Share this post


Link to post
Share on other sites

Completely, utterly off topic: I was looking at the 1992 (verses 1990) version of the "Designing Cards and Drivers..." book and I ran across this paragraph on page 275, Chapter 12:

 

Quote

The Macintosh LC is shipped with 256 KB or 512 KB ofVRAM (video RAM). With this configuration, main memory is not used for storing video data. If VRAM is not installed, it is possible to use main memory for video storage, though it is not recommended. With this configuration, main memory can only support the 640 x 480 monochrome video mod

Uhm, whut? Has anyone ever actually tried this?

Share this post


Link to post
Share on other sites
11 minutes ago, Gorgonops said:

Completely, utterly off topic: I was looking at the 1992 (verses 1990) version of the "Designing Cards and Drivers..." book and I ran across this paragraph on page 275, Chapter 12:

 

Uhm, whut? Has anyone ever actually tried this?

I was aware of this but I haven't tried but it's mostly because I don't have a working LC at the moment.

 

I assumed that this function was possible because the LC and Classic shared components (so in the LC with dedicated VRAM it does color, but in a Classic without VRAM it does monochome), but apparently this wasn't the case; though similar, the video chips are different between the two models. So why did this function exist? No idea. Maybe for testing? This is one of the reasons I was curious as to why Apple used so many custom chips. If you already had a chip that can do what you need it to, why build another one that's only slightly different? Seems kind of a waste.

 

31 minutes ago, Gorgonops said:

68040 PDS might be another kettle of fish. Doesn't the 68040 require external arbitrators to handle different-width peripherals? (I kind of thought that was one of the reasons why Apple was so much in the business of using 68040->68030 bus bridge chips in so many cheap-o desktop and Powerbook models...)

IIRC there's a blurb in the 68040 UM about a dedicated Motorola chip that you can implement in your design that basically does this, possibly by acting as an '030 bus interface bridge. 

I'd still like to know why Moto decided to abandon the byte steering and dynamic bus sizing features in the '040. They were useful features and I doubt Apple was the only one making use of them.

Share this post


Link to post
Share on other sites
7 hours ago, NJRoadfan said:

The Zorro II bus on the Amiga is pretty much a direct pinout of the 68000 (24-bit address bus) plus a bus arbitration chip called Buster to handle DMA. Zorro III upgraded this to 32-bits all around and expects a 68030 or 68040.

Sounds about right, Zorro II = SE PDS (with multiple slots?) and Zorro III = SE/30 Multislot PDS. Why did Commodore not use slots with mor pins rather tha going the multiplexing route. Seems overly complicated for no apparent reason from the start. They could have used a slot extension like the PC or a more capable, higher density connector like EuroDIN?

 

DMA was damn cool at that time in that market segment though. Protected memory? Not at all familiar with Amiga.

Share this post


Link to post
Share on other sites
9 hours ago, trag said:

The biggest challenge is finding a development board with enough IO brought out to connectors to interface with the 680x0 bus.   I don't  think there is one.    A custom board would be needed.   And someone or some service would have to solder down the multi-hundred pin BGA FPGA.

Again I'm wondering just ho many address and data lines need be implemented for 8-bit/16-bit/24-bit Video cards? Am I wrong in my guess that along with most(?) control signals you'd need only 24 data lines and 5 address lines for a 24-bit VidCard implementation?

 

The Radius Pivot LC manages to output some-resolution-or-other from half the 68020 I/O bus.

 

s-l1600.jpg

 

edit: the Pivot would also be half the 68030 bus in LCIII Q605/LC475, the Quadra 630 and all its descendants that used the LCIII PDS. NICs for the entire series never crossed over to the 32-bit side of the split LCIII split connector AFAIK. Was there a 16-bit Vidcard for that slot and did it need to use the LCIII slot extension?

 

Edited by Trash80toHP_Mini

Share this post


Link to post
Share on other sites
44 minutes ago, Trash80toHP_Mini said:

Am I wrong in my guess that along with most(?) control signals you'd need only 24 data lines and 5 address lines for a 24-bit VidCard implementation?

Yes, you're wrong. The VRAM is addressed as a chunk of memory so you need at minimum the same number of address lines as accessing that much RAM would take. So for a 1MB VRAM card you'll need to decode at least 20.

 

(On the memory buffer side you'll only need half that many if you're using DRAM with row/column multiplexing, but the PDS bus doesn't do that.)

Share this post


Link to post
Share on other sites

So how many lines are necessary to address enough VRAM to do 720p @24-bit?

 

edit: are we barking up the wrong tree with a standard FPGA development board engine? Do any graphics chipset developers have a hardware/software development kit that would be more suitable for massively parallel(?) throughput or is any other type of programmable logic available? Might FPGAs be used in parallel on a custom board that might be produced for applications requiring high numbers of DIO pins? Dearth of DIO pins appears to the bane of development in the Pi world.

 

I'm out of my depth entirely at this point. I've got all three levels of the card development docs in my head w/o the knowledge base to make sense out of or really do anything with it that's more than rudimentary. Never figured I'd have need to delve into Inside Macintosh and not at all sure I could deal with it? I hope pointing out the layered nature of Developing Cards and Drivers series was a good enough contribution. iLost! :blink:

 

If anyone could search Inside Macintosh and the Developer CD series for TOBY Card PAL Listings I think finding them anywhere would be a big contribution. If we can get the well documented TOBY card up and running as "PDS hardware" in an emulation environment I feel that would be a huge first step forward, but what the h**l do I know? :mellow:

Edited by Trash80toHP_Mini

Share this post


Link to post
Share on other sites

 

2 hours ago, Trash80toHP_Mini said:

Again I'm wondering just ho many address and data lines need be implemented for 8-bit/16-bit/24-bit Video cards? Am I wrong in my guess that along with most(?) control signals you'd need only 24 data lines and 5 address lines for a 24-bit VidCard implementation?

 

The Radius Pivot LC manages to output some-resolution-or-other from half the 68020 I/O bus.

 

edit: the Pivot would also be half the 68030 bus in LCIII Q605/LC475, the Quadra 630 and all its descendants that used the LCIII PDS. NICs for the entire series never crossed over to the 32-bit side of the split LCIII split connector AFAIK. Was there a 16-bit Vidcard for that slot and did it need to use the LCIII slot extension?

 

I'd figure the video controller would be responsible for the pixel depth, since it could have a wider 24 or 32-bit memory bus on the card compared to the 16-bits available through the LC PDS slot. For example, there was a Lapis ProColorServer 24-bit LC video card on eBay recently. Like the Radius card, it's only a 16-bit LC slot interface. There were very few 32-bit LC III PDS cards developed; I don't remember ever seeing one in person. I assume most of the ones that did exist were video cards or accelerators.

Share this post


Link to post
Share on other sites

A quick tidbit regarding the LC PDS:

 

Originally designed for the LC and its 16-bit system bus, this connector was built to directly interface to the 68020 at 16MHz. The LC PDS also included audio and FPU present pins in addition to a handful of others to allow the use of cards with some sound capabilities (specifically the IIe card) and to install an FPU in a machine where a socket was not present on the logic board, an example of which is shown in the picture of the Radius Pivot video card above and also familiar to people with early LC PDS Ethernet cards.

The LC II kept the 16-bit system bus and clock speed, the only change being a move to the '030, but since they shared the same bus protocols, the LC PDS still operated exactly the same as in the LC. This is also true of the Color Classic, which was essentially a slightly redesigned LC II logic board in a compact case.

The LC III (and III+, Color Classic II, Performa 520, 550, and 275, all the same basic architecture) changed things a little: the system bus was now 32-bits wide, but thanks to the 68030's dynamic bus sizing feature, a legacy 16-bit LC PDS card can be installed with no problems. Because the system bus was now 32-bits wide, a small extension to the original LC PDS slot was added that provided the signals to expand the slot up to a full 32 bits. Now known as the LC III PDS, this extended slot became Apple's standard low-end expansion slot across their entire consumer line for about 4 years, with (most) cards originally designed for the LC able to be used in up to a Power Macintosh 53/63xx series machine. Of course, after the switch to the 68040, the LC PDS is no longer a true PDS: it resides on an '040-to-030 bridge chip of some sort, and depending on which computer it's in. These psuedo-PDS slots also ran at a fixed 16MHz whether they were 16 or 32-bits and regardless of the system bus speed of the computer. The original Comm Slot is basically an LC PDS in a different form factor, with both running at a fixed 16MHz off of the '030 bridge chip.


What I'm not entirely sure about is whether the LC/LC III PDS was always clocked at 16MHz, even in the LC III and III+ where the system bus is 25 or 33MHz respectively. ISTR that it was stated in some of the Apple dev material that it is always fixed at 16MHz, but I don't know how it's achieved: the LC III PDS is still directly connected to the processor's pins in the LC III and III+ with no buffers or arbitration devices in between. 

Share this post


Link to post
Share on other sites
1 hour ago, Trash80toHP_Mini said:

So how many lines are necessary to address enough VRAM to do 720p @24-bit?

Actually, I realized I kind of lied when I said you needed 20 address lines for 1mb... *if* you were using 32 bit wide memory. In that case you'd need 18 address lines. (Since your 1mb would be organized as 256 kilowords.) Not that it makes much difference. Anyway... since 720p 16x9 is just under a megapixel for 24 bit you'll obviously need about 3mb of RAM, so... still talking 20 lines.

 

My vague thoughts on this problem of affordable FPGA boards not having enough I/O to decode both the PDS/Nubus slot *and* a control bus for a RAM bank actually sort of boil down to, well, okay, so don't do it all in the fpga. Just spitballing here: use the FPGA to handle the output circuitry and timing generation, implement the bus decoding with some simple PLDs, and do address generation with a couple binary counters. (Which are choreographed by the FPGA, along with the bus contention signals.) Offload the bus decoding and effectively multiplex a few control signals into your 20-something line RAM address bus with the counters and I see you getting away with, I dunno, maybe as few as around 50 I/Os on the FPGA proper? Not to handwave excessively, but this is essentially how a real mid-90's level of integration card would work.

 

I'd also suggest using plain old SRAM instead of DRAM for simplicity. 4MB of it, which should be ample, isn't going to cost that much.

Share this post


Link to post
Share on other sites

Yay! You guys have broken it down to the my toddler building block playtime on the floor level again! [:)] FPGA is up on the adult's train set build level, the board looks like a bog magical black box from down here.

 

On the NuBus conversion of the PDS development board front:

Check out the first chapter in Designing_Cards_and_Drivers_for_the_Macintiosh_II_and_SE_-_1987 for the NuBus primer. It describes the first rev, discrete logic implementation of NuBus (pre-NuChip) in the first release Macintosh_II. Breaking the NuBus block out to its basics for logic analysis and PAL raid missions on the Mac_II.1 Logic Board is the current line of investigation in the age old SE/30/NuBus project. Treating that discrete logic as a black box for the Model T performance NuBus version of the proposed Indy Brick Yard Roadster performance PDS dev board seems the thing to keep simmering on the back burner.

 

@Franklinstein very glad to hear tell of that 16-bit/24-bit VidCard for the LC Slot! Such would be a great first look at the discrete PLD/SRAM FPGA feeding funnel proposed by @Gorgonopsabove.


 

 

Edited by Trash80toHP_Mini

Share this post


Link to post
Share on other sites
9 hours ago, Gorgonops said:

I'd also suggest using plain old SRAM instead of DRAM for simplicity. 4MB of it, which should be ample, isn't going to cost that much.

Just to note, I did do a quick look for parallel high-speed SRAMs, and maybe "that much" is a matter of degree. For chips that can be hand soldered (vs. BGA) you're probably looking at around $7-10 a megabyte. That's peanuts compared to what it cost once upon a time, but I know how people in this particular corner of the hobby freak out at the thought of spending money for new build stuff...

Share this post


Link to post
Share on other sites

Yeah, there is that. ::) But if you put NuBus and Zorro II/III multiplexing layers into the same black box for later wouldn't you be opening development up to a much less stingy, more technically oriented hobby freak population with a far more advanced retro-dev cult? That's part of what I thinking of (along with enlistment of the emulation gang) as insane levels of collaboration.

 

Implementing this proposed VidCard at that 16-bit input/24-bit output LC board level would be exactly what's needed for the VidCard Project to branch off to 16-bit PowerBook VidCard, LC, CC & Co. expansion interfaces.

 

 

< ridiculous tangent mode? >

 

Keeping the single Slot ID decoding model of the Futura IISX VidCard/NIC Daughtercard would something to put a'simmering on the other back burner. The LC Slot Macs (and to a point, the IIsi/SE/30 twins) are in need of a dual purpose expansion card. 100bT/WiFi antenna and 24-bit 720p HDMI out the backplane slot cover of a CC or Quadra 605 anyone? [}:)]

 

< /ridiculous tangent mode? >

 

edit: not to get too ridiculous here, but designing to a form factor compatible with the smaller of 190/5300 or 1400 video cards would be a great pie in the sky miniaturization goal. If nothing else, keeping it to a form factor compatible with the LC spec and the Blackbird PDS spec seems the thing to do. Out of my depth again here, but would keeping I/O to that 16-bit bottleneck put the proposed VidCard on a PCMCIA card as well? Just spitballin' here as well as in the tangent above, but there are backplane PCMCIA Slot conversion cards for all manner of retro toys, including TAM applications as well as the PC and Amiga crowds.

Edited by Trash80toHP_Mini

Share this post


Link to post
Share on other sites

 @trag here are a couple of part numbers and a logo for that 68040 PDS connector. One is on what may be a handy edge card interface for a prototyping board adapter?

 

68040-PDS-Connector-DevBoard-Adapter-1.thumb.JPG.333c957637d514cbdf37353d7302b102.JPG

 

 

D5527 is on a 6100/DOS Card Adapter? H3489 is on a Quadra 610 riser? Add H1573 as the part number on the connector of one of my Quadra 700 boards.

 

 @dlv it's not the crisp 1080p HDMI output of your dreams, but I'm wondering what speed differential there might be between 720p on 16-bits of your Quadra 950's PDS vs. its internal video? I'm all but certain it'd beat the snot outta the NuBus Card you said you wanted to stick in there. [;)]

Share this post


Link to post
Share on other sites

I was the one that picked up the 24bit LC Lapis ProColorServer on eBay recently. Let me know if you need to know anything about it. It works, I just can't get the extension to load.

Share this post


Link to post
Share on other sites

You find all the best bits nic! I was just looking through the NuBus in SE/30 reboot you kicked off for applicable goodies here. That card is a fabulous conquest. From my vantage point getting a new tech version of it hooked into the NuBus Test Card's bits will wind up being the row to hoe at some point. For now, ramping that 16/24-bit 020 PDS design example to the three slot capable 030 PDSwould be the thing to accomplish. Dumbing it back down to the single $E interrupt 020 LC PDS will be a walk in the park by comparison. Interfacing with NuBus will be complicated, but a lot easier than dealing with it during basic hardware development.

 

I'll think about posting reference materials I've put together here and there in a unified bus theory thread. There's way to much and most of that discussion that data will be tangential, but important for this feasibility study. Patching a block diagram together from 680x0 to the discrete component implementation of Macintosh_II.1NuBus onto NuBus and breaking it out to the Macintosh II Video Card (TOBY) with or without the NuBus Test Card's well documented PAL (code and listings) would put it all on one annotated page. That and second page with the 680x0 PDS block diagram of same for comparison will be a neat thing to develop. [:)] It annoys me no end the way Apple presented the Cards and Drivers documentation in seemingly unrelated chunks. One fully documented example for building working card wold have been nice.

 

Got HiRes pics of that puppy to post yet, nic?

 

Edited by Trash80toHP_Mini

Share this post


Link to post
Share on other sites
57 minutes ago, nickpunt said:

Ask and ye shall receive

w00t! I'd say so and me has serious enjealous. What a beautiful example of LC Slot Goodness and beautifully documented. We have tone!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×