Page 1 of 1

dual ported SRAM for co-processing

Posted: 07 Jun 2019, 12:06
by cmpxchg
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 ?


Re: dual ported SRAM for co-processing

Posted: 08 Jun 2019, 08:27
by cmpxchg
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 ?

Re: dual ported SRAM for co-processing

Posted: 08 Jun 2019, 09:42
by monsonite
They are listed in the 1983 TTL Handbook - see page 2-404 in the link below ... 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 ... 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.

Re: dual ported SRAM for co-processing

Posted: 08 Jun 2019, 12:32
by cmpxchg
> 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:

The 34-pin serial connection is basically serial with MFM:
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

Re: dual ported SRAM for co-processing

Posted: 12 Jun 2019, 15:21
by cmpxchg
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]

[4] ... t_Macs.txt

Re: dual ported SRAM for co-processing

Posted: 19 Oct 2019, 03:06
by PurpleGirl
An idea I had was to put 32k dual-ported RAM on 2 Gigatrons and do crisscross addressing. Instead of using the high bit to address larger memory, it is used to switch a multiplexer and address the memory on the other machine. So the low 32k is the local Gigatron, and the high 32k is the other Gigatron. And you can do it that way on both, so each boot into their own ROM and RAM and access the others' RAM through software. Thus, port 2 on machine A is the upper 32k bank of machine B, and port 2 on machine B is the upper 32k bank of machine A. So if you need a specific location on machine A from machine B, just add 32k to the address.

(Alternatively, they could be daisy-chained. The first one can address the low memory of the 2nd one as high memory via dual-ported SRAM like above. The 2nd one could have a separate high bank of 2-ported SRAM and it could be shared with something else, whether that be another Gigatron, a packaged FPU, or whatever. With an FPU, the OUT or X-OUT could be the instruction bus, and the data can be passed in memory. Using dual-ported RAM and the right code, you could probably make do without an IRQ or DMA line.)

With the crisscross dual-ported SRAM mod, someone could modify the ROMs to get most of the video and sound processing out of the first one and remove the keyboard/joystick input (and possibly emulator) and user programs from the 2nd one. And if you want to pass commands, the X-out of the first one can be connected to the IN of the second one (UART removed or changed to a buffer chip). So you could have the first one to safely run native code (or emulators) without as much work while the 2nd one could handle sound, video or anything else you want it to handle (like an FP emulator or software commands for commonly used video and sound routines). You could even extend the sound and video software on the second one by adding more waveforms, commonly used sound samples, sprites, and textures. Connecting the input and output (along with the dual-ported mods) could enable you to have a special emulator on the 2nd one to accept commands through the IN port to do common tasks. So you could just tell the second one to play a sound for a certain length of time, clear the screen, fill the screen with textures, etc.

Edited: Reading the above conversation about devices, PIO access would likely be the easiest to pull off with a Gigatron as long as you stay cycle-exact. DMA would be harder to pull off since that would likely require a /Halt signal and a way to move access of the RAM to another device. Adding that would make the video impossible without another pipeline with separate memory (ie., a dual-threaded Gigatron). Dual-ported SRAM might make DMA transfers easier to implement.