6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Fri Sep 20, 2024 6:48 pm

All times are UTC




Post new topic Reply to topic  [ 544 posts ]  Go to page Previous  1 ... 8, 9, 10, 11, 12, 13, 14 ... 37  Next
Author Message
 Post subject: Re: POC Version 2
PostPosted: Sat Nov 03, 2012 9:41 pm 
Offline
User avatar

Joined: Sat Sep 29, 2012 10:15 pm
Posts: 899
BigDumbDinosaur -what software do you use to lay out the boards?

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut


Top
 Profile  
Reply with quote  
 Post subject: Re: POC Version 2
PostPosted: Sat Nov 03, 2012 10:01 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
enso wrote:
My hope at the time was to eliminate the PC entirely - I have yet to do this....

With your FPGA board, it's a simple matter to add a VGA connector with a small resistor network to generate a usable video output.


Top
 Profile  
Reply with quote  
 Post subject: Re: POC Version 2
PostPosted: Sun Nov 04, 2012 12:25 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8389
Location: Midwestern USA
enso wrote:
BigDumbDinosaur -what software do you use to lay out the boards?

I do both schematic and PCB work in Express PCB's software. I use them for getting boards made.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject: Re: POC Version 2
PostPosted: Sun Nov 04, 2012 12:27 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8389
Location: Midwestern USA
enso wrote:
How is Picasso visually?

It appears to be okay. The caveat is my testing has been limited to connecting it to a monitor, apply 5 volts and looking at the built-in splash page.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject: Re: POC Version 2
PostPosted: Tue Nov 06, 2012 3:12 am 
Offline
User avatar

Joined: Sat Sep 29, 2012 10:15 pm
Posts: 899
It was MicroVGA mentioned earlier that looks HORRIBLE! You can look at their screenshots if you want to lose your lunch. I can't believe they went through the trouble of designing the device and did not bother getting or making a readable font... I bought it 2-3 years ago, and their website is still showing the horribleness...

Stay away from that thing.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut


Top
 Profile  
Reply with quote  
PostPosted: Thu Nov 08, 2012 5:59 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8389
Location: Midwestern USA
As I mentioned in another post, POC activities have been minimal the last few weeks due to other time demands. POC V2 is still in the "vapor-ware" phase and not much has been committed to the design.

In thinking about it, I decided (as I also mentioned a number of posts ago) to abandon the Express PCB Proto-Pro PCB service and go with a production service printed circuit board to get around the hole and area limits of the Proto-Pro service. Doing so will allow me to embed the SCSI hardware on the board and dispense with the separate host adapter (and its effects on bus loading). Also, with more board area I decided I can take a different tack with RAM.

The original plan was to include one meg of RAM in the form of two 512 KB SRAMs. That would be enough memory to support 8 to 12 simultaneously running processes, with room left over for buffers and other data structures. The SRAMs would have been soldered right to the PCB, this being an essentially non-expandable design.

After more consideration, I have decided to try out Garth's 4 MB DIMM, which is a plug-in unit. The DIMM is physically quite small and would stand vertically off the PCB, much like the way memory modules do in PCs. As there are eight SRAMs on the DIMM, the CPLD will have to generate eight separate chip selects according to the effective address being emitted by the 65C816 and addressing rules related to memory protection and ZP and stack remapping. The logic to do so is only slightly more complicated than that required for two SRAMs.

The increased RAM will have the corollary effect of allowing more processes to be supported, as well as use of more RAM for buffers and data structures. While this is a nice enhancement, the real purpose of the exercise is to see how well the circuit will perform with the 4 MB DIMM and whether it can be clocked up to 20 MHz. The SRAM count will definitely add to bus loading and in my opinion, overwhelm the 65C816's ability to drive the buses. The use of aggressive bus drivers (74ABT logic, which packs a pretty good punch and is very fast) should compensate for the loading and, it is hoped, result in stable performance at 20 MHz.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject: Re: POC Version 2
PostPosted: Thu Nov 08, 2012 6:57 pm 
Offline

Joined: Sat Dec 13, 2003 3:37 pm
Posts: 1004
Sounds great BDD. The extra RAM will make it nice to give you extra resources. Even in your testing, I can imagine 1MB getting tight on you.

Have you given any thought toward DMA with the SCSI? The 4MB will give you extra elbow room if you ever want to play with that as well. And it's such a nice, compact DIMM to boot.


Top
 Profile  
Reply with quote  
 Post subject: POC Version 2: Status
PostPosted: Thu Nov 08, 2012 7:41 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8389
Location: Midwestern USA
BigDumbDinosaur wrote:
POC V2 is still in the "vapor-ware" phase and not much has been committed to the design...

I was on the phone earlier today with someone and the discussion eventually wandered onto POC and its status. My friend made a suggestion that I may consider.

POC V2 is substantially different than V1 in the use of a CPLD for glue logic. A concern that is somewhat unrelated to that feature is how well a circuit would perform at high speed with Garth's DIMM (which I recently purchased from him). The DIMM will introduce increased bus loading that is well above what exists with POC V1 and its single SRAM. The suggestion was to build a "POC V1 and a half" that incorporates the DIMM and a basic bank address latch circuit, but otherwise uses the glue logic of POC V1. The rationale would be that performance comparisons would be more relevant.

In fact, the bank address latch could be skipped, since most of the loading will be a result of the PCB connections and the input capacitance of each SRAM on the DIMM (eight total SRAMs). In this case, the glue logic would be completely unchanged, as only the chip select of the first SRAM on the DIMM would be active. The SRAMs are 10ns parts, so their performance wouldn't be a factor in the overall system performance. The only tricky part will come in doing a PCB layout that fits within the EPCB Proto-Pro limits and has enough room for the DIMM—adding the DIMM means adding 46 new holes to the PCB, and there's a 650 hole limit.

I'll have to think about it.

whartung wrote:
Sounds great BDD. The extra RAM will make it nice to give you extra resources. Even in your testing, I can imagine 1MB getting tight on you.

1MB would be enough to run 8-12 processes—assuming they don't need gobs of RAM to do their thing. This would certainly be adequate to prove some concepts. However, as we all know, RAM is a lot like money: you can always use more of it. :D The extra RAM would mean that in the early stages of development I wouldn't have to devote a lot of time to being resource-efficient. The time would be better spent on developing and refining algorithms and later on, efficiency gains could get into the picture.

A real value of more RAM is that more buffers can be allocated for SCSI I/O, which would certainly enhance throughput. And when I get a functioning filesystem in place, I'll have elbow room for the requisite data structures.

Quote:
Have you given any thought toward DMA with the SCSI? The 4MB will give you extra elbow room if you ever want to play with that as well. And it's such a nice, compact DIMM to boot.

I have, as the design of the SCSI controller (53C94) is tilted in favor of DMA. The current SCSI driver, which can generate a burst throughput approaching 500KB/sec with a 10 MHz Ø2 clock, simulates DMA control via some circuit trickery and careful programming. So it's certainly clear that a good DMA setup would do a lot for SCSI performance.

My long-term goal in this regard is to try to implement a single-channel DMA controller (DMAC) in a CPLD. I have a basic algorithm that would be able to move a byte every two Ø2 clock cycles, which would theoretically achieve 10MB/sec throughput with a 20 MHz Ø2 clock. This would work best with the 53CF94, which is a faster device than the 53C94 (the former can be operated with a 40 MHz clock) and thus might not require wait-stating.

A single-channel DMAC that has been optimized for the DMA protocol of the 53C(F)94 would be very efficient and might not eat up too much in the way of CPLD resources. Ideally, the DMAC would exist within the same CPLD that handles the glue logic, but that may not be practical. I've not yet looked at it though...I'm being careful to avoid creeping featurism. POC V2's purpose is mostly to prove out the PLD glue logic, demonstrate that memory mapping and hardware protection work properly, and hopefully achieve the goal of 20 MHz operation.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
PostPosted: Thu Nov 08, 2012 8:55 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1738
Location: Sacramento, CA
BigDumbDinosaur wrote:
The only tricky part will come in doing a PCB layout that fits within the EPCB Proto-Pro limits and has enough room for the DIMM—adding the DIMM means adding 46 new holes to the PCB, and there's a 650 hole limit.


Digikey has a few left of the SMT version of the female socket, their part # S5732-ND. Cost is $3.54

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/


Top
 Profile  
Reply with quote  
PostPosted: Thu Nov 08, 2012 9:18 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8389
Location: Midwestern USA
8BIT wrote:
BigDumbDinosaur wrote:
The only tricky part will come in doing a PCB layout that fits within the EPCB Proto-Pro limits and has enough room for the DIMM—adding the DIMM means adding 46 new holes to the PCB, and there's a 650 hole limit.

Digikey has a few left of the SMT version of the female socket, their part # S5732-ND. Cost is $3.54

Interesting. It has a somewhat bigger footprint than a through-hole socket, but would not require any holes except where necessary to get to the bottom PCB layer. The SMT mounting may have implications for distributed capacitance as well, perhaps less.

Thanks for the reference.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject: Re: POC Version 2
PostPosted: Thu Nov 08, 2012 9:27 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8510
Location: Southern California
If time and money were no object, it would be interesting to experiment and see how much stress the SMT ones can handle without ripping the foils away. For our products, I don't dare put connectors on SMT, since vibration, dropping it, etc. would be a killer. In the memory module situation, even pulling it out of the socket without damaging the mother board might be a challenge. There's too much leverage on it. Thru-hole OTOH makes like a rivet. All our connectors are thru-hole, and get mounted after the automated SMT assembly portion. SMT sockets' pins stick out the sides and take more room too (as I see BDD just commented), keeping you from putting other parts as close. If you have to have a lot of vias to connect the SMT socket anyway, you might not save many holes by using SMT.

Imagineering has good prices for low production volumes and no limits on holes or anything else, although they're not as economical if you only want a couple of boards. I don't think you'll ever have an order from them of less than about $300. I had them do my memory module when I got 100 boards made. I chose them for it after having them do quite a few boards for work and we were quite happy with their work and prices. Before that, I've used PCB Express (not to be confused with Express PCB in BDD's post) and remember having an order for a few small boards being under $100 several years ago. You can use any CAD with them that puts out gerber files.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
 Post subject: Re: POC Version 2
PostPosted: Thu Nov 08, 2012 9:57 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8389
Location: Midwestern USA
GARTHWILSON wrote:
If time and money were no object, it would be interesting to experiment and see how much stress the SMT ones can handle without ripping the foils away.

I see that this socket has a pair of pilot posts that engage holes in the PCB. Presumably they would add some needed stability to the assembly, although it doesn't appear that they would do anything about straight-line pull forces. The PCI(E) sockets on a typical PC motherboard are through-hole with pilot posts and seem to be pretty solidly anchored.

Quote:
For our products, I don't dare put connectors on SMT, since vibration, dropping it, etc. would be a killer. In the memory module situation, even pulling it out of the socket without damaging the mother board might be a challenge. There's too much leverage on it.

I tend to agree. SMT is great for parts that get installed and then are not subjected to any physical forces, e.g., an SRAM soldered into a PCB. OTOH, disengaging 46 pins means pulling straight up on the DIMM, which means you are pulling on the solder tabs, plus you might not be pulling exactly coincident to the DIMM's plane, thus applying lateral force. It would probably be okay for our hobby usage, since presumably we're not going to be abusive of our stuff. However, accidents can happen...

Quote:
SMT sockets' pins stick out the sides and take more room too (as I see BDD just commented), keeping you from putting other parts as close.

In the case of your DIMM, that's not much of a liability, since the DIMM's effective footprint is slightly greater than that of the socket into which it's plugged (thickness-wise). Also, I'd suspect that you couldn't get too dense with the connectors due to needing room to route traces in between them. Of course, most of the connections are DIMM to DIMM, since the buses are shared between modules. The odd connections would be chip selects and write-enables, if separate write-enable connections are being used for each DIMM. In my case, I'm going to wire the two write-enables together, since I don't have an application where I'd want to write-protect one half of the DIMM.

Note to Garth: a future enhancement to consider for your DIMM design might be to separately bring out the /WE connection for each SRAM. This feature would allow implementation of hardware write protection with 512KB granularity, instead of the 2MB granularity now available. It means more pins, of course, and thus a slightly larger assembly. I'm going to have some write-protection in POC V2's logic, but only for small areas near the lower end of the memory map that are occupied by the kernel (especially the ISRs in the $00E000-$00FFFF range). The protection would come from the CPLD based upon the address on the bus, not by physical manipulation of the DIMM's /WE inputs. A write directed to a write-protected area would not assert /WD (the general write data signal) but would trigger an ABORT interrupt to the MPU, since that would constitute an illegal access.

Quote:
If you have to have a lot of vias to connect the SMT socket anyway, you might not save many holes by using SMT.

That's a distinct possibility, which even arises with small SMT devices, such as discrete logic. In my present POC V2 PCB layout, I ran into that with the bus buffers, which are SOIC (50 mill) packages. In this case, the substantially smaller package was of value even though via were required to get to the bottom layer.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject: Re: POC Version 2
PostPosted: Fri Nov 09, 2012 6:06 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8510
Location: Southern California
BigDumbDinosaur wrote:
GARTHWILSON wrote:
If time and money were no object, it would be interesting to experiment and see how much stress the SMT ones can handle without ripping the foils away.

I see that this socket has a pair of pilot posts that engage holes in the PCB. Presumably they would add some needed stability to the assembly, although it doesn't appear that they would do anything about straight-line pull forces. The PCI(E) sockets on a typical PC motherboard are through-hole with pilot posts and seem to be pretty solidly anchored.

On these that are more hobbyist-friendly (I even have wire-wrap sockets for them), I find I kind of have to rock the module carefully as I pull it out. Otherwise by the time you get enough force to pull all the pins out at once, they suddenly come and you end up bending pins because one end comes out slightly before the other and it comes up and it's crooked. You've no doubt seen that where IDCs were pulled off of pin headers.

Quote:
Quote:
SMT sockets' pins stick out the sides and take more room too (as I see BDD just commented), keeping you from putting other parts as close.

In the case of your DIMM, that's not much of a liability, since the DIMM's effective footprint is slightly greater than that of the socket into which it's plugged (thickness-wise).

True, but few parts would be as tall as the socket itself so as to be able to reach the module, so I don't think there's any concern there.

Quote:
Note to Garth: a future enhancement to consider for your DIMM design might be to separately bring out the /WE connection for each SRAM. This feature would allow implementation of hardware write protection with 512KB granularity, instead of the 2MB granularity now available. It means more pins, of course, and thus a slightly larger assembly.

It would take it out to 50 pins which is a more standard size. I wanted to go as small as possible and still have enough distance between the ICs to solder them by hand (which I had to guess). Unless I run out of boards (it would be great to get an order for hundreds of these!), my next products will be something else to facilitate home computer construction. I have ideas, but nothing in the plans yet.

Quote:
The SRAM count will definitely add to bus loading and in my opinion, overwhelm the 65C816's ability to drive the buses. The use of aggressive bus drivers (74ABT logic, which packs a pretty good punch and is very fast) should compensate for the loading and, it is hoped, result in stable performance at 20 MHz.

It would be great if you could make it so you could try it both with and without the bus drivers to compare speed.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
 Post subject: Re: POC Version 2
PostPosted: Fri Nov 09, 2012 5:33 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8389
Location: Midwestern USA
GARTHWILSON wrote:
BigDumbDinosaur wrote:
The SRAM count will definitely add to bus loading and in my opinion, overwhelm the 65C816's ability to drive the buses. The use of aggressive bus drivers (74ABT logic, which packs a pretty good punch and is very fast) should compensate for the loading and, it is hoped, result in stable performance at 20 MHz.

It would be great if you could make it so you could try it both with and without the bus drivers to compare speed.

This is where the idea of building "POC V1 and a half" would get into the picture. That unit would be exactly like POC V1.0 except for the DIMM in place of the single SRAM. There would be no bus drivers and no bank latch circuit. If I do build it I'd run it without the SCSI host adapter and its bus loading. I already know that POC V1.1 (the bug-fixed version of POC V1.0) is 100 percent stable at 12.5 MHz with no SCSI present. It will boot at 15 MHz with a 26C92 DUART in place of the 2692 DUART, but is flaky at that speed. So 12.5 MHz would be the reference speed.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject: Re: POC Version 2
PostPosted: Sat Nov 17, 2012 11:10 pm 
Offline
User avatar

Joined: Mon Apr 23, 2012 12:28 am
Posts: 760
Location: Huntsville, AL
BDD:

Just cruising the forum to catch up on some threads, and found that the link to Vince Briel's PockeTerm that rwiker provide is up. It must have been down when you tried it. It does appear to be a simple VGA/PS2 based terminal emulator that may be down your alley. Source and schematics are available on the site as well.

_________________
Michael A.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 544 posts ]  Go to page Previous  1 ... 8, 9, 10, 11, 12, 13, 14 ... 37  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 37 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: