Expansion bus

[marcelk]

My other interest in this expansion though is actually to see if I could use my Gigatron as an ASCII terminal for my PiDP-11 somehow

[I think I want a Gigatron to drive my newly arrived IMSAI 8080 replica kit.]

To those of you playing along at home, Jörg's clever signal mapping is implemented in the provisional SYS functions, but not in these "prototype/(pre-)alpha" boards yet. I'm too lazy to make new boards for as long as software support still only exists at the lowest possible level. Therefore you'll need wiring patches with these. With sockets the lid won't close any longer, so this requires some planning to get it right in one go.

The design difference is this:

Code: Select all

Bus  Rev.1909 ROM v4+
     = Rev.4  or DEVROM
     hardware software
---  -------- ---------
A0   B0       SCLK
A1   B1       (unused)
A2   /SS0     same
A3   /SS1     same
A4   /SS2     same
A5   /SS3     same
A6   SCLK     B0
A7   MOSI     B1
A15  (unused) MOSI

The wiring patches I applied myself:

Code: Select all

U1 pin 3 --> A15 = J3
U1 pin 4 --> A0  = J1 pin 10
R1 pin 1 --> GND = C3 south

Furthermore, the resistor values are 2.2K, not 10K.

IMG_5144.jpeg (340.79 KiB) Viewed 13859 times

You can see I didn't patch the banking at all, and I even just soldered in a 32K memory. The improvised resistor ground pad is damaged and scorched because I replaced these 4 times.

On the software front, last month the provisional SPI function has relocated in the development ROM. The addresses should be stable after this. The code I now toggle in for 16 blinking lights is this:

Code: Select all

50
:59 40 5e 78 59 78 2b 24
:e3 3 2b 26 11 9 b 2b
:22 59 78 b4 fa 11 15 b
:2b 22 b4 cb 11 9 b 2b
:22 59 7c b4 fa ff 50 0
a0
:75 59 0 2b 79 cf 76 59
:1 2b 79 cf 76 59 14 5e
:79 1a e 5e 7a cf 76 59
:15 5e 79 1a e 5e 7a cf
:76 1a f 8c ff 35 3f ab
:63 ff
a0R
 

Or disassembled:

Subroutine

Code: Select all

0050 59 40      LDI   $40       MCP23S17 "write"
0052 5e 78      ST    $78
0054 59 78      LDI   $78       Send buffer (start)
0056 2b 24      STW   $24
0058 e3  3      ADDI  3         Receive buffer (end)
005a 2b 26      STW   $26
005c 11  9  b   LDWI  $b09      SYS_ExpanderControl_v4_40
005f 2b 22      STW   $22
0061 59 78      LDI   $78       Enable SPI0
0063 b4 fa      SYS   40
0065 11 15  b   LDWI  $b15      SYS_SpiExchangeBytes_v4_134
0068 2b 22      STW   $22
006a b4 cb      SYS   134
006c 11  9  b   LDWI  $b09      SYS_ExpanderControl_v4_40
006f 2b 22      STW   $22
0071 59 7c      LDI   $7c       Disable SPI0
0073 b4 fa      SYS   40
0075 ff         RET             Return (to main)
0076 50  0      .WORD $0050

Main

Code: Select all

00a0 75         PUSH
00a1 59 0       LDI    0        MCP23S18 "IODIRA" register
00a3 2b 79      STW   $79
00a5 cf 76      CALL  $76       IODIRA = 0 (=output)
00a7 59 14      LDI   $14       MCP23S17 "OLATA" register
00a9 5e 79      ST    $79
00ab 1a  e      LD    $0e       Gigatron frameCount
00ad 5e 7a      ST    $7a
00af cf 76      CALL  $76       OLATA = [frameCount]
00b1 1a  f      LD    $0f       Gigatron serialRaw
00b3 8c ff      XORI  $ff
00b5 35 3f a5   BEQ   $00a7     Continue until key pressed
00b8 63         POP
00b8 FF         RET             Return (to WozMon)

This key press detection is a bit simple, and often it bails out on the original `Enter' that started the program. So you have to hit that very briefly.

This should fully document what's required to make these work. After the summer break I hope I can return to this development and expand on the software for card reading.

[xopr]

Thanks for the elaborate update, Marcel: this was a good kickstart for me.

The soldering and modification was more or less painless; here are some snapshots of my progress (sorry for the bad quality pictures):

expander_cutoff.jpeg (105.16 KiB) Viewed 13807 times

Note that I had to cut off a bit of Expander J2 pins 4, 9 and 13 (Gigatron RAM socket pins 18, 23 and 27) for the IC socket to fit snugly on top.
It might be hard to see on the picture.
I had positive results using a set of 0.47mm diameter connector pins (these to be exact, note the're not symmetrical)

expander_rewiring.jpeg (122.11 KiB) Viewed 13807 times

I ran the patchcables between the board and IC but that made the IC fit less optimal; still I was able to solder all pins.

expander_assembled.jpeg (166.63 KiB) Viewed 13807 times

As you can see, I used a socket for the RAM (and a lot of sockets on the Gigatron as well; make sure you don't use sockets in the Gigatron for U29, U30, U32 and U33 as they will then touch the SPI header solder connection.

Also, by using a RAM socket the lid floats about 3mm on top of the Gigatron, but the ridges are high enough to keep the lid in place.

Since I didn't have an expander IC available, I connected an Arduino in slave mode (with this information and a modified version of this code)

• SPI0 MISO (pin 1)->Uno pin 12
• SPI0 SCKL (pin 3)->Uno pin 13 (will generate led activity)
• SPI0 MOSI (pin 4)->Uno pin 11
• SPI0 SS (pin 5)->Uno pin 10
• SPI0 GND (pin 6)->Uno GND

Don't use the arduino SPI programming header since SS is tied to reset to initialize the bootloader which will crash the Gigatron.

I would only recommend one small improvement for the next revision expander board: to place J3 a bit more 'south', to make room for a right angle pin pointing 'east'.

[xopr]

It took me a while to get everything on track (and I'm not sure if I can spend more time on it this week), but I have a proof of concept written in C that outputs the Gigatron's keyboard input on screen (using tinyfont) and to the SPI0 port as well.

Here is my result: https://youtu.be/R9liFeYZV7E

The code I used for the Arduino is: https://gist.github.com/xopr/05ce68a74a ... cd8429b0bb
The Terminal code I used is: https://gist.github.com/xopr/16377abde5 ... a7ef3991e5
Note that the code is really sloppy and I messed up the

Code: Select all

Newline_ex

function; but for a proof of concept, it works.

Of course one does need ROM v4 for this to work (otherwise it displays an error)

(Note that I had to modify the Makefile to get it to build: I removed the quotes around

Code: Select all

$^

for target

Code: Select all

.SECONDARY: # Instructs 'make' not to delete intermeditate .o files
%.gt1: %.o $(libObjects)
	$(LCC) $(LCCFLAGS) $^ -o "$@"

[marcelk]

Congratulations! That's a really excellent achievement, and clearly a lot of effort and dedication when into this result. Thanks for sharing!

(Note that I had to modify the Makefile to get it to build: I removed the quotes around

Code: Select all

$^

for target

Code: Select all

.SECONDARY: # Instructs 'make' not to delete intermeditate .o files
%.gt1: %.o $(libObjects)
	$(LCC) $(LCCFLAGS) $^ -o "$@"

May I ask what platform and/or "make" program you're using? I like to improve the Makefile. I usually test just on macOS and with that I sometimes miss things like this.

[Edit: I get it! The issue is now addressed in GitHub. Thanks for reporting]

[monsonite]

Hi xopr, Marcel,

This is great progress, and something I must reproduce on my Gigatron.

I like your thinking of using an Arduino as a programmable SPI slave. You can program the Arduino to do whatever you want in response to a few SPI commands.

There is scope for a common set of commands to access the I/O. Firmata and Txtzyme are two that spring to mind.

https://www.arduino.cc/en/reference/firmata

http://txtzyme.com/view/welcome-visitors/view/txtzyme


The SPI slave Arduino can act as GPIO, a UART, 6 channels of ADC, timers and PWM, additional RAM, ROM or EEPROM and interface with a whole variety of additional low cost, off the shelf hardware. It could even support an Ethernet controller such as the Wiznet W5100 or the Microchip ENC28J60 which would allow the Gigatron access to the Web.

It might even simplify the means to access an SD card. The Arduino could act as the "disk controller" and just serve a binary or ascii file back to the Gigatron. If the ATmega328P is too small, then there is always the ATmega1284P with 128K ROM, 16K RAM and 32 I/O pins which could be the ultimate peripheral.

Is this cheating? No - ever since the early 1960s, computers have used small specialised peripheral processors to handle I/O. Such as the CDC 160 https://en.wikipedia.org/wiki/CDC_160_series

"As long as it's outside of the box - that's OK"

regards


Ken

[xopr]

Thanks Marcel and Ken.
To be fair, I'm just standing on the shoulders of giants here

Also, I want to mention that the original Newline function is genius to a level of mind boggling (for me least); it took me two days to figure out how the ScreenPos upper byte and videoTable offset were aligning at 'the right time'.
After I got the clue that their offsets go from 8 to 127, it was a bit more apparent to me, but I wasn't able to get the same results with the 5+1 pixel high tinyfont.
Also, since I'm using the SYS_VDrawBits_134 command (and leaving the last 2 bits zero), I'm not able to write the last line (or at least the wrap-around area) without crashing the Gigatron since I'm drawing outside the video memory. (a SYS_Draw3x5) that accepts a word would be a welcome feature here

For reference of the `make` error: I'm using GNU Make 4.1 (x86_64-pc-linux-gnu) on an Ubuntu MATE 'bionic' 18.04.2 LTS (4.15.0-54-generic #58-Ubuntu SMP x86_64); the quotes caused all the object files to be referenced as one parameter.

I hope hook up the Gigatron to the network (or terminal server) one day, and with minimal changes to the current terminal and arduino proof of concept (exchange a byte every possible cycle) it might actually be really easy to create a VT05 terminal (although not implemented in Linux, but VT100 is).
Note that the ESP8266 wifi chips that can be programmed with the Arduino IDE also have a SPI slave possibility if I'm not mistaken. Yes, they have ridiculous amount of processing power, but it might be a nice shortcut to hookup the Gigatron to internet.

I also quickly looked whether it was easy to modify the built-in loader so I have the controller port free for a keyboard whilst being able to load a program via sendFile.py->Arduino serial->SPI but that at a first glance this seems more daunting than anticipated.

regards,

Martijn

[xopr]

Not sure if it is the first connected Gigatron, but here is a teaser video where I connect over (Arduino) USB serial to my laptop:
https://youtu.be/vtE6ngzq8qA
(Sorry for the terrible video quality)

The blurry text on the left Linux terminal executes

Code: Select all

systemctl start serial-getty@ttyACM0.service

(after I did a 'systemctl enable' and uploaded the terminal program onto the Gigatron)
I'll have to cleanup my code a bit before posting (I currently have square eyes)

[monsonite]

Martijn,

Fantastic work!

I'm looking forwards to replicating this on my Gigatron.

regards


Ken

[xopr]

Thanks, Ken

I've just updated the Terminal code and Arduino code, but I have to add some remarks:

• the code is still in really bad quality (mediocre at best)
• the Arduino needs the reset-on-serial disabled or the terminal server won't recognize the serial port correctly; newer revisions have a scratch/solder pad for that (which I scratched through and soldered a jumper onto): it should be in the middle of an Arduino uno with a label "Reset on"
• most of the escape codes are not implemented (and not tested)
• somehow backspace on screen coming from the server doesn't work (it's not char 8 or 127): it draws a sort of arrow on an empty line and writes "DK" after some input
• I switched from `SYS_VDrawBits_134` to raw pixel blitting which makes it noticeably slower (it will overflow the 9600 baud serial buffer and characters will be lost). The positive side is that it now can use the last line as well without quirky line skipping.
• I tried "Midnight commander" and "lynx", but no fruitful results yet (brow.sh is another take I didn't even try)
• I added a keyrepeat mechanism that doesn't work over SPI (it resends the same character multiple times; it worked in the emulator, so I disabled it by adding "if ( oldchar == keypress ) spiData = 0;"

If you want to test the Terminal in an emulator (without Expander hardware), you can edit the function:

Code: Select all

byte SPIExchangeKey( byte _key )
{
	return _key; // No hardware, skip exchange
}

to skip the SPI part and test, for example, arrow keys or some escape codes (<ESC> H is 'home', to mention just one)

Cheers,

::Martijn

[jurkstas]

But what about a generic expansion port/bus for memory-mapped peripherals? Could the SPI be one of such peripherals, having it's own memory address/range? Or should it be an integral part of Gigatron sometime in the future?