6502.org • View topic - Memory map design with 2-to-4 line decoder?

View unanswered posts | View active topics

Board index » 6502.org Users Forum » Hardware

All times are UTC

Memory map design with 2-to-4 line decoder?

Page 2 of 2

[ 22 posts ]

Go to page Previous 1, 2

Previous topic | Next topic

Author

Message

BigDumbDinosaur

Post subject: Re: Memory map design with 2-to-4 line decoder?

Posted: Fri Feb 22, 2013 6:28 am

Joined: Thu May 28, 2009 9:46 pm
Posts: 8384
Location: Midwestern USA

scotws wrote:

BigDumbDinosaur wrote:

See below for a little 2692 code to get you started. These defs will also work with the 26C92 but would be incomplete in some respects.

Thanks, I'll squirrel that right away for future use. -- Fascinating story about the terminals. Point 4, that would have been the IRIS people (http://www.point4data.com/)? What kind of machine would that have been?

One and the same. Most of their later boxes, before they abandoned proprietary technology in the early 1990s, were built around Motorola 68K MPUs and full-height ST-506/412 hard drive mechanisms. The older hardware was built around bit-sliced MPUs, which was customary prior to the development of the 68K line. The "Point 4" name came from an achievement of the late 1970s, when they had reduced the machine cycle time to 0.4 microseconds, which in 1978-or-so, was something about which to brag.

Interesting historical fact: IRIS (Interactive Realtime Information System) was the model upon which the Lt. Kernal hard drive subsystem for the Commodore 64 and Commodore 128 computers was based. Fiscal Information Systems, who developed the Lt. Kernal during about a year after the C-64 went on sale, was a Point 4 VAR and had detailed knowledge of the inner workings of IRIS. Lloyd Sponenburgh and Roy Southwick borrowed on that knowledge to create the Lt. Kernal DOS. One of the IRIS features that was particularly difficult to emulate was something called polyfiles, which were roughly equivalent the C-ISAM file structure found in UNIX. Fiscal succeeded in implementing the keyed index part of the polyfile design and left it to the programmer to mate a key file with a CBM relative file to create a true indexed database system.

As it turned out, using a relative file was not a good solution for a variety of reasons, one being that reading or writing a record required several individual disk accesses. This was a critical concern because the ST-506/412 hard drive mechanisms of time (mid-1980s) had 30-50 millisecond seek times, very slow compared to a modern SCSI drive's typical 2-3 milliseconds. Also, ST-506/412 devices lacked any intelligence and had to be paired with a SCSI controller card, which had the dubious pleasure of translating SCSI logical block addresses (LBA) into C-H-S internal addresses that matched the drive's geometry. Hence the controller's performance added to the lag between when a disk access was requested and when it was received. When this characteristic of the hardware was combined with the need for multiple accesses per record (which always meant time-consuming seeks, since no such thing as track buffering existed back then), response seemed more like what you'd get from a floppy disk.

I ended up using a custom file structure that was based on the contiguous data file built into the LK DOS, and addressing the file as a large array, using 32 bit integer math to generate a logical block offset in the file that would relate to the notion of a record number. Since the computation of the position in the file was done on the host machine, rather than by read side-sectors on the disk (as was done with relative files), only one disk access was required to read or write a record (using a SCSI feature that permitted the reading and writing of multiple blocks per command). This got record retrieval down to little more than the seek time of the drive. The file structure also allowed locking of records to prevent conflicts on a multiplexed system.

Fiscal essentially duplicated the mass storage aspects of IRIS on the Lt. Kernal, and by the time the final version of the DOS had been released, a C-128 in FAST mode connected to a Lt. Kernal could retrieve data faster than could be accomplished with a 1750 RAM unit, certainly a lot faster than competing units of the time (e.g., CMD).

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

Top

whartung

Post subject: Re: Memory map design with 2-to-4 line decoder?

Posted: Sat Feb 23, 2013 1:22 am

Joined: Sat Dec 13, 2003 3:37 pm
Posts: 1004

BigDumbDinosaur wrote:

Back when dumb terminals (e.g., the venerable WYSE 60) were in widespread use, a port concentrator or terminal server was used to connect multiple terminals to a single I/O port on the (mini)computer. The 2698 was often used in these concentrators to help keep the chip count under control. For each 2698, a total of eight 1488 and eight 1489 line drivers was required. There is at least one company that sells an eight port TIA-232 plug-in card for PCs that uses the 2698, but I don't recall anymore who it is or where one might acquire one.

Back in the day, we used a multiport card for Unix based PCs. But pretty sure it was a custom ASIC. It supported, like, 20-24ish ports on a single card, using RJ-11 or RJ-45 jacks. The board itself wasn't dominated by chips either, it was a pretty clean board.

We drove them at 19.2k, didn't really have a need for higher. I dunno if that was the maximum for them or not.

But it was a great card and really compact. Wish I could remember the name.

Ah, the good ol days of hand assembling 9 pin D connectors (using those kits where you shoved the pins in to the empty D connector). "Let's see is the connector straight or null? Is the cable straight or null? Do I need 5 pins or will 3 work?" Actually, no, I don't really miss that

Top

BigDumbDinosaur

Post subject: Re: Memory map design with 2-to-4 line decoder?

Posted: Sat Feb 23, 2013 7:30 am

Joined: Thu May 28, 2009 9:46 pm
Posts: 8384
Location: Midwestern USA

whartung wrote:

Back in which day (year)? There were several companies that produced PC hardware-compatible concentrators, the most technically advanced of the bunch being the Equinox SuperSerial line that could be expanded to 512 ports total per machine. Their design had an ASIC called the SuperSerial processor on the card, with an external panel containing the connections (DB-25 or RJ-45 ten pin jacks). The ASIC was really a custom microcontroller that completely offloaded the serial I/O from the host machine, buffering it on the card and then periodically becoming a bus master and delivering the data to the kernel. Rather than have hundreds or thousands of interrupts each time a terminal screen was painted, only a few interrupts were required. The loading was very light, even with dozens of terminals in use.

BTW, both of my servers here are equipped with Equinox hardware, one with an eight port setup (the machine on which I developed the POC code) and the other with 16 ports. The second server is also my company fax server, complete with a U.S.R. Courier modem.

When I mention the use of the 2698 I'm going back to the late 1980s before the general availability of terminal controllers like the SuperSerial units.

Quote:

Ah, the good ol days of hand assembling 9 pin D connectors (using those kits where you shoved the pins in to the empty D connector). "Let's see is the connector straight or null? Is the cable straight or null? Do I need 5 pins or will 3 work?" Actually, no, I don't really miss that

It wasn't that hard. It was entirely dependent on whether a DTE or DCE was being connected, for which we always used detailed hookup diagrams. The actual connector assembly was tedious, however. I did a lot of installations with 40-50 terminals, a small army of serial printers and several modems, and all of that was, at the time, a case of attaching DB-25 connectors to cables at both ends. In the mid-1990s, I devised a hookup schema using CAT5 cable and modular jacks that could be punched down or crimped, cutting the cable hookup time by nearly 80 percent. I used a wiring scheme that allowed the cable and termination endpoints to be used for serial I/O or Ethernet (10Base-T or 100Base-T).

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

Top

PaulF

Post subject: Re: Memory map design with 2-to-4 line decoder?

Posted: Sat Feb 23, 2013 5:45 pm

Joined: Mon Dec 08, 2008 6:32 pm
Posts: 143
Location: Brighton, England

scotws

I've spotted another error on your decoding schematic. On the 74HC139, the WRITE' line should connect to the X2 output not the X1 output (Pin 10 not Pin 11). Pin 11 will pulse low when Phase2 is low and R/W' is high - i.e. at the start of every read cycle. Pin 10 pulses low when Phase2 is high and R/W' is low, which is what is needed for a WRITE' pulse. Sorry I didn't notice this sooner.

_________________
Shift to the left,
Shift to the right,
Mask in, Mask Out,
BYTE! BYTE! BYTE!

Top

whartung

Post subject: Re: Memory map design with 2-to-4 line decoder?

Posted: Sun Feb 24, 2013 3:16 am

Joined: Sat Dec 13, 2003 3:37 pm
Posts: 1004

BigDumbDinosaur wrote:

Early 90's. And it was the Equinox cards. That's exactly what it was.

Quote:

It wasn't that hard. It was entirely dependent on whether a DTE or DCE was being connected, for which we always used detailed hookup diagrams. The actual connector assembly was tedious, however.

I'm talking about determine what state what random connector was in, and what state what random patch cable was in. It was always getting mixed up, different folks did things differently. It was always a great source of fun and excitement.

Top

scotws

Post subject: Re: Memory map design with 2-to-4 line decoder?

Posted: Mon Feb 25, 2013 7:12 pm

Joined: Mon Jan 07, 2013 2:42 pm
Posts: 576
Location: Just outside Berlin, Germany

PaulF wrote:

I've spotted another error on your decoding schematic.

Ay. Thanks, life is crazy at the moment, will try to get around to correcting it ASAP. Also, I am now the proud owner of a bunch of '139s, so at some point I hope to be breadboarding the design out of general principle.

Top

scotws

Post subject: Re: Memory map design with 2-to-4 line decoder?

Posted: Thu Feb 28, 2013 11:17 am

Joined: Mon Jan 07, 2013 2:42 pm
Posts: 576
Location: Just outside Berlin, Germany

So I've breadboarded the chip select logic -- that mess of wires on the included photo. The chip in the middle is the '139 line select, the one on the bottom left a '132 for the NOT signal. The contraption on the small breadboard the top is another '132 with two of the NAND gates combined with a capacitor to produce a "blink" signal to simulate Phi2. The dip switch on the bottom is A15, A14, A13 and R/W' from left to right. There is some basic color-coding, with white address lines, blue write, grey read, and yellow control. The LED block is taken from the schematic, with RAM, UART, VIA, ROM2 and ROM1, in that order.

PaulF wrote:

On the 74HC139, the WRITE' line should connect to the X2 output not the X1 output (Pin 10 not Pin 11).

Yes, this is quite clear once you see the circuits do their thing (though the blinking lights are far more pretty in the original version). Thanks again.

(I have no idea why the schematic is on its side, it's fine on my MacBook here. Sorry.)

Attachments:

ÜSq0 Chip Logic Test sws 20130227 V3.jpg [ 600.58 KiB | Viewed 293 times ]

ÜSq0 Chip Logic Test sws 20130227.JPG [ 523.8 KiB | Viewed 293 times ]

Top

Page 2 of 2

[ 22 posts ]

Go to page Previous 1, 2

Board index » 6502.org Users Forum » Hardware

All times are UTC

Who is online

Users browsing this forum: Paganini and 10 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