dual ported SRAM for co-processing

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice.
Post Reply
Posts: 7
Joined: 07 Jun 2019, 11:44

dual ported SRAM for co-processing

Post by cmpxchg » 07 Jun 2019, 12:06

I was wondering if the 32 kb extension as proposed by Marcel could alternatively be used with dual-ported SRAM instead

This way two gigatrons side to side can have shared memory, share memory structures for high-speed I/O, using spinlocks to protect data structures,
and have truely bidirectional I/O with two 'threads' each running from their own ROM

IDT seems to be one of the only few selling dual-ported SRAM @ 5V, but price is above $50 but available in hand-solderable TQFN package
It does feature /busy outputs, which could be ignored for simplicity reasons, or think on some logic to suspend or stretch a clock of the other
unit while writing

Using a small FPGA to simulate such device might work too - Lattice has a few small FPGAs with third party OSS tools available - but the 5V barrier is a bit high - all I/0 would need to be levelshifted

are there other idea's to make a 'dual-core' 'transputer' like support feasible with 5 volt technology ?


Posts: 7
Joined: 07 Jun 2019, 11:44

Re: dual ported SRAM for co-processing

Post by cmpxchg » 08 Jun 2019, 08:27

Fitting more into the TTL nature of the gigatron - part availability around the 70's/80's, I did also find dual-ported registers/SRAM,
SN74AS870 and SN74AS871
This is only 16 bytes, perhaps good enough for a simple queue or register-bank that can be polled by a coprocessor.
Does anyone know when this part was first introduced to the 74xxx range ?

Posts: 50
Joined: 17 May 2018, 07:17

Re: dual ported SRAM for co-processing

Post by monsonite » 08 Jun 2019, 09:42

They are listed in the 1983 TTL Handbook - see page 2-404 in the link below

http://bitsavers.trailing-edge.com/comp ... a_Book.pdf

It looks like they are an extended version of the 74xx670 which contained 4 x 4bit registers - which did appear much earlier, they are in the 1976 databook page 7-526

https://www.smcelectronics.com/DOWNLOAD ... TABOOK.PDF

The 1976 TTL Databook is a great read. Not only does it illustrate the extent of the range that was available in the "Golden Age of TTL", but offers more examples of useful applications - such as making an extendable register file from the 74xx374. Page 7-477.

I wonder whether a standard single port RAM could be accessed by two processors, if those access cycles were guaranteed not to occur simultaneously?

Conceptually could you run the two Gigatrons on alternate phases of the clock, or arrange the memory access logic to control alternate access?

I think that you would need to have the clocks at 90 degrees offset - so that 4 distinct clock periods could be generated. CPU1 would gain access in periods 1 and 3, and CPU2 would have access in periods 2 and 4

I note that the RAM write enable signal /WE is already OR'ed with CLK1 - so that writes are constrained to the half cycle when the clock is logic low. The RAM output enable /OE can become active as soon as the bottom 2 bits of the Instruction latch are decoded, but there is an enable input on the 74HCT139 which could be gated with the necessary clock phase.

All of this assumes that the RAM is sufficiently fast access time to allow four operations in a single clock period, and that the ALU and decode logic can also keep up.

Posts: 7
Joined: 07 Jun 2019, 11:44

Re: dual ported SRAM for co-processing

Post by cmpxchg » 08 Jun 2019, 12:32

> I wonder whether a standard single port RAM could be accessed by two processors, if those access cycles were
> guaranteed not to occur simultaneously?

This would mean locking the whole address bus, since the main RAM (but not the ROM) are on there as well - see page 37 of the manual.
Halting the other processor (interrupting clock without glitches ?) would harm timing of its video output etc etc, and an additional mux is needed
to switch the bus to another address input. I think dual-ported RAM is a nice way to separate concerns.

The second processor could be used to do not worry about video timing and all overhead, and only do I/O related memory preparation
GPI and GPO registers
UART transmit connection with discrete shift registers, fifo's presented as a ringbuffer to the other processor
UART receive using edge-triggered receive clock and shift register, latching into another register

A floppy disk drive interface with block-based I/O to the other CPU, hardware to generate the MFM signalling for a floppy disk controller,
so that both old floppies as well as floppy drive emulators (already for $20) can be used for storage.
There was even a hacker who stored music data directly on floppy: https://www.youtube.com/watch?v=ziVXF_tM4Gw

The 34-pin serial connection is basically serial with MFM: http://www.interfacebus.com/PC_Floppy_Drive_PinOut.html
As a bonus, there will be no reliance on other modern NAND flash interfaces like SDcard and USB storage,
and no dependency on specific wear-levelling algorithms, licensed interfaces, or optimisations for filesystems that can fail if used
by firmware of all modern hardware. All computers can interface to a 3.5" floppy, via USB or otherwise, and 1.4 MB is more than enough
for gigatron purposes.

AUI interface to use one of the earlier ethernet interfacing methods,

A way to run a IP stack on the secondary ROM to run an IRC client on the video gigatron to connect to the internet

Posts: 7
Joined: 07 Jun 2019, 11:44

Re: dual ported SRAM for co-processing

Post by cmpxchg » 12 Jun 2019, 15:21

Steve Wozniak made a custom (floppy) disk controller using a statemachine from discrete chips [1], later integrated in a single chip. This logic seems to have lasted all the way to the original iMacs running on PowerPC derived memory busses.
An integrated floppydrive controller like NEC µPD765 and the Intel 82072/7 from old stock still seems a bit expensive these days, ~$7, and have quite high clockspeeds and their own 24 MHz crystal driver. Interfacing with such controller also has some software complexity [2], and requires timely busywait readout or DMA.

Decoding and encoding the timing cricital M2FM or MFM in software from disk with aid of a shift register might work. But Apple II GCR [3] might be
even more tricky, detecting a sector and starting the write at exactly the right moment, and finding the right drives to control spindle speed.
A highspeed-software-defined statemachine like the gigatron might be able to output an encoded (lookup table?) consistent MFM encoded 250 or 500 bits per second, or 48 (24 after division?) clocks per output bit @ 12 MHz, and receive these bits as well.

Implementing a full filesystem on homecomputers often used a disk-ROM and with some tokenized basic extensions implemented as hooks for the basic interpreter that came with the original computer (on MSX IIRC).

Perhaps a custom software-controlled statemachine next to the gigatron itself can help out here, reacting to commands in shared-memory / dual ported RAM registers. Other I/O like serial/UART, V21 modems, network could find a place here as well.

Is there a little more info available on the development of the logic around floppy disk drive controllers around Apple I/II/Lisa/Macintosh time ? [4]

[1] https://en.wikipedia.org/wiki/Integrated_Woz_Machine
[2] http://www.isdaman.com/alsos/hardware/fdc/floppy.htm
[3] https://en.wikipedia.org/wiki/Group_coded_recording
[4] http://www.folklore.org/StoryView.py?st ... t_Macs.txt

Post Reply