Expansion bus

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice.
monsonite
Posts: 41
Joined: 17 May 2018, 07:17

Re: Expansion bus

Post by monsonite » 18 Mar 2019, 18:03

In response to mwwhited

Once you have an expansion bus capable of SPI and banks of RAM, there are many ways in which this project could evolve.

At the moment - the Gigatron cpu is intimately tied to the process of generating video, consuming much of the processors available clock cycles - but this need not always be the case.

With hindsight and access to more modern devices - such as James Bowman's Gameduino - it would be possible to create full video without having to draw every pixel. Gameduino was originally developed to allow the Arduino to be used to develop 8 bit games. More recently, David, "The 8-Bit Guy" has used it to provide video from his 65C816 retro computer project. https://www.youtube.com/watch?v=ayh0qebfD2g (14 mins in onwards).

Gameduino works on an SPI bus and requires a list of the display objects to be drawn to be sent once per frame. This reduces the video bandwidth from about 1 million pixels (bytes) per second to about 10k bytes/s SPI data.

With extra hardware comes the necessity of extra software - and with more software the requirement for more memory. Non volatile memory would be attractive - One option might be to fit a 32K x 8 ferroelectric RAM - which retains its data after power off. This could be added to the expansion board and accessed when A15 is high. At about $15 it would be a quick-fix to the problem of losing one's code when the power goes off. I can't see myself developing apps that need more than 32K bytes, but others may differ in their opinion of this.

This brings up the question whether people want to develop code using tools that are self-hosted on the Gigatron or using tools running on a laptop. Part of the attraction of my computing youth, was that it was just you and the machine - there was no support other than LOAD and SAVE to a cassette recorder.

User avatar
marcelk
Posts: 269
Joined: 13 May 2018, 08:26

Re: Expansion bus

Post by marcelk » 01 Apr 2019, 08:58

jwolfram wrote:
07 Mar 2019, 09:14
Transfer a fixed number of bytes is suitable for writing to a SD card but not for reading. For init (must be do at low frequency) and read we need polling. I will explain how I did SD-card access in my library:
I started to look at sdcard.c in more detail and compare it to the explanation in the PDF document posted early in the thread. I note that you seem to do everything in multiples of 8 bits. Also when waiting for the answer after CMD0 (Reset) for example.

Lets zoom in on polling for the card's response for CMD0. Does that mean that:
  1. The reply byte is always byte-aligned, with MSB=0, and zero or more whole 0xff bytes preceding it, or
  2. The reply byte can be misaligned, with any number of 1-bits leading to it, but we don't care as long as we see that 0 come in somewhere in the stream(*).
(*)And some additional clock transitions after receiving the reply byte don't matter, as long as MOSI is high when we do that.

xopr
Posts: 12
Joined: 05 Jun 2018, 12:05

Re: Expansion bus

Post by xopr » 30 Apr 2019, 15:28

Although I didn't have enough time to play with the Gigatron the last year, I'm really excited about the possible I/O expansion.
Since I'm a little more confident with (Commodore) Basic than GCL, I was wondering if it would be possible to speak to I/O that way.

This is probably completely silly (and slow) to do, but I'm wondering if it would work..

I tried to gather the snippits of information from Notes.gtb and the first proof of concept from Marcel.
I'm just not sure if:
  • the address bytes need to be swapped like in WozMon
  • it would work at all in Basic

Code: Select all

'
' Setup vCPU SPI transfer
'
'Send buffer (start address)
20 poke 129,17:'LDWI
21 poke 130,0:'00
22 poke 131,5:'05
23 poke 132,43:'STW 
24 poke 133,36:'24 
'Receive buffer (end address)
25 poke 134,227:'ADDI
26 poke 135,3:'03
27 poke 136,43:'STW 
28 poke 137,38:'26
'SYS_Control
29 poke 138,17:'LDWI 
30 poke 139,9:'09 
31 poke 140,11:'0b 
32 poke 141,27:'STW 
33 poke 142,34:'22
'Enable SPI0
34 poke 143,89:'LDI 
35 poke 144,120:'78 
36 poke 145,180:'SYS
37 poke 146,250:'fa; (270-40/2)
'SYS_SpiTransfer
38 poke 147,17:'LDWI
39 poke 148,0:'00
40 poke 149,13:'0d
41 poke 150,43:'STW
42 poke 151,34:'22
43 poke 152,0bB4:'SYS
44 poke 153,205:'cd; (270-130/2)
'SYS_Control
45 poke 154,17:'LDWI 
46 poke 155,9:'09 
47 poke 156,11:'0b 
48 poke 157,27:'STW 
49 poke 158,34:'22
'Disable all
50 poke 159,89:'LDI
51 poke 160,124:'7c
52 poke 161,180:'SYS
53 poke 162,250:'fa
'Return
54 poke 163,255:'RET

'
' Main program
'
' Fill SPI buffer
60 poke 1280,90
61 poke 1281,165
62 poke 1282,90
' Execute command and read result
70 d=usr(129):'Call vCPU routine at 81
71 ?peek(1283):'504.506
72 ?peek(1284)
73 ?peek(1285)

monsonite
Posts: 41
Joined: 17 May 2018, 07:17

Re: Expansion bus

Post by monsonite » 30 Apr 2019, 18:13


With extra hardware comes the necessity of extra software - and with more software the requirement for more memory. Non volatile memory would be attractive - One option might be to fit a 32K x 8 ferroelectric RAM - which retains its data after power off. This could be added to the expansion board and accessed when A15 is high. At about $15 it would be a quick-fix to the problem of losing one's code when the power goes off. I can't see myself developing apps that need more than 32K bytes, but others may differ in their opinion of this.
I noticed today that the cost of 128K byte SPI FRAMs has dropped significantly to make them attractive for program storage.

From Farnell https://uk.farnell.com/rohm/mr45v100ama ... dp/2903680 at just under 5 Euros before tax.

A 256K x 8 device is also available for about 7 Euros.

Ferroelectric RAM is non-volatile on power-off and almost immune to wearing out. These devices are intended for working with an SPI bus and are packaged in 8 pin packages.

One idea would be to fit one of these devices to a modified BabelFish (Arduino) - and basically take the role that the EEPROM currently has for program loading and saving. Very large programs could be saved and loaded from TinyBASIC.

The SPI FRAM make a good candidate for the SPI expansion pcb so that programs could be held locally and be loaded into the main memory from the menu, when required - without having to resort to the complexity writing a FAT and dealing with SD cards.

It could be considered to be a "cartridge" drive, and if designed on a thumbnail sized pcb - could plug in to any of the available SPI ports. Multiple devices could be added for banked storage. Will we ever need 1Mbyte of storage on a Gigatron?

The device is 3V3 supply - so would need a 3V3 regulator and some of level shifters (either resistors or 74LVC126) so that it will play nicely with the 5V and TTL logic levels.

I have ordered a couple of devices to play around with, there is already an Arduino SPI RAM library for reading these SPI memory devices.

I have also found some cheap Chinese Ebay suppliers of adaptor boards to convert various surface mount packages to DIL. These will be handy for expansion projects - especially the 10nS 128K x 8 RAM - that no longer appears to be available in a DIL package.

User avatar
marcelk
Posts: 269
Joined: 13 May 2018, 08:26

Re: Expansion bus

Post by marcelk » 30 Apr 2019, 19:05

xopr wrote:
30 Apr 2019, 15:28
This is probably completely silly (and slow) to do, but I'm wondering if it would work.. I'm just not sure if:
  • the address bytes need to be swapped like in WozMon
  • it would work at all in Basic

Code: Select all

'
' Setup vCPU SPI transfer
'
'Send buffer (start address)
20 poke 129,17:'LDWI
[... snip ...]

' Fill SPI buffer
60 poke 1280,90
61 poke 1281,165

Cool! It can work with some relocation :-). Under BASIC, you need to find another place in memory to store this program. BASIC itself is sitting at 1280 / 0x500, and it has more variables in the zero page than WozMon.

This BASIC program is a bit too large to be stored in the 512-byte EEPROM of Pluggy McPlugface. But it may fit in an Arduino Uno's EEPROM. And you can always load it from a laptop/PC with sendFile.py.

WozMon just looks at bytes and is unaware of addresses in memory, so sees the same byte order as everyone else.

My own idea is to push this SPI expander sub-project further using C, not GCL. The attraction of possible FAT support is that we can exchange files with other computers this way, completely untethered and without additional software/adapters/etc on those computers. Before I didn't really see a way to do that all in vCPU/GCL and maintain my sanity as well. But now that LCC has fallen out of the sky, there are options... Still, I think it could take some months to get near there.

xopr
Posts: 12
Joined: 05 Jun 2018, 12:05

Re: Expansion bus

Post by xopr » 03 May 2019, 14:09

marcelk wrote:
30 Apr 2019, 19:05
...
Cool! It can work with some relocation :-). Under BASIC, you need to find another place in memory to store this program. BASIC itself is sitting at 1280 / 0x500, and it has more variables in the zero page than WozMon.
...
I dug around the memory model, how BASIC is using the remaining memory and came to the conclusion that I'll abuse the part where the BASIC source is located, starting at an arbitrary 70A0, and I'm using 75A0 for the SPI buffer. This will still allow for 254 source lines.

To make it more compact, I wrote a kind of hacky HEX DATA handler to ease repetition of the POKE commands (lines 60 to 220 that search the memory looking for lines that begin with a single quote).
Since I don't have the daughter board or the newer ROM (yet ;) ), I can't really test it, but I guess it should work similar as your firsts sample in WozMon.

The program takes about 4 seconds to parse itself.

Code: Select all

'TEST I/O
'''''''''''''''''''''''''
' Increase speed
10 mode 3:poke 42,0:cls
' Check for ROM v3x
30 if peek(33)>40 goto 60
40 ?"ROM can't do I/O"
50 end
60 ?"Initializing.."
' Iterate the 3 BASIC
' program columns to
' find the 'DATA' fields
70 j=210:a=28832
80 for l=0 to 791
90 for c=0 to 2
100 p=7074+256*l+32*c
' find set of remarks
110 if peek(p)<>39 goto j
120 j=230
' Translate and store HEX
' DATA into dedicated mem
130 for d=0 to 9
140 t=peek(p+d*2+1)-48
150 s=peek(p+d*2+2)-48
160 if t > 10 t=t-7
170 if s > 10 s=s-7
180 poke a,16*t+s
190 a=a+1
' TODO:Branch every 90B
200 next d
210 next c
220 next l
' Set SPI data
230 poke 30112,165
240 poke 30113,90
250 poke 30114,165
260 ?"Done. Executing.."
270 d=usr(28832)
'''''''''''''''''''''''''
' DATA (case sensitive)
9996'11A0752B24E3032B2611
9997'090B2B225978B4FA1100
9998'0D2B22B4CD11090B2B22
9999'597CB4FAFF0000000000
To run it on a ROMv3 or older (which effectively will not work since the SYS_Control and SYS_SpiTransfer are not available), add the following line:

Code: Select all

20 goto 60:'skip check

User avatar
marcelk
Posts: 269
Joined: 13 May 2018, 08:26

Re: Expansion bus

Post by marcelk » 04 May 2019, 02:03

xopr wrote:
03 May 2019, 14:09

Code: Select all


'''''''''''''''''''''''''
' DATA (case sensitive)
9996'11A0752B24E3032B2611
9997'090B2B225978B4FA1100
9998'0D2B22B4CD11090B2B22
9999'597CB4FAFF0000000000
Cool. That's completely in the spirit of the original Tiny BASIC. See here and scroll down to the 'Strings' section... :)
xopr wrote:
03 May 2019, 14:09
Since I don't have the daughter board or the newer ROM (yet ;) ), I can't really test it, but I guess it should work similar as your firsts sample in WozMon.
We have a few extra of those SPI prototype boards for those interested in playing along. They need the same wiring patches as I posted in this thread earlier, and assuming you can reprogram your own EPROM and have your own chips, we can share them "as-is" for just the postage costs. Just drop us an e-mail.

monsonite
Posts: 41
Joined: 17 May 2018, 07:17

Re: Expansion bus

Post by monsonite » 05 May 2019, 19:14

xopr,

I like your Tiny BASIC hack for code entry - nice.

I suppose when Tiny BASIC was written, PEEK, POKE and USR were the "tactical nukes" of the language.

I'll get a chance to try that tomorrow.

4 seconds to parse itself - is that with Mode 0 (no blank lines) video?

Ken

xopr
Posts: 12
Joined: 05 Jun 2018, 12:05

Re: Expansion bus

Post by xopr » 06 May 2019, 08:56

marcelk wrote:
04 May 2019, 02:03
...
We have a few extra of those SPI prototype boards for those interested in playing along. They need the same wiring patches as I posted in this thread earlier, and assuming you can reprogram your own EPROM and have your own chips, we can share them "as-is" for just the postage costs. Just drop us an e-mail.
I ordered a Minipro (TL866II) and a cheap UV eraser; I will wait my turn and enter the queue if I have all the hardware in place: I don't want to stand in the way of the real hardware hackers :) .
Thanks for the offer, Marcel!

monsonite wrote:
05 May 2019, 19:14
xopr,

I like your Tiny BASIC hack for code entry - nice.

I suppose when Tiny BASIC was written, PEEK, POKE and USR were the "tactical nukes" of the language.

I'll get a chance to try that tomorrow.

4 seconds to parse itself - is that with Mode 0 (no blank lines) video?

Ken
Thanks Ken :)

I try and speed the process up by entering mode 3 (in the program itself): I tested it in mode 0 and it will take up almost a minute, so I guess it's best to do 'complex' stuff in mode 3 (it would actually be handy to have a mode hblank-only, in a similar spirit as the C64 tape loader, but I guess since I'm doing this in BASIC, I'm asking for slow speeds).
Now that I think of it; I probably could write a two-stage loader: one that loads a vCPU loader to load the rest :P

Also: I only tested it on the emulator which has ROM v3, so it will execute a fraction of a bit longer when the actual SPI calls are in place.

Cheers,


::Martijn

natevw
Posts: 1
Joined: 12 Jun 2019, 18:58

Re: Expansion bus

Post by natevw » 12 Jun 2019, 19:13

Count me in the same position as "xopr" — I have recently ordered a programmer as well as EPROM eraser and would be interested in helping test the expansion board. I have some experience maintaining all of SPI (https://github.com/natevw/pi-spi), SD Card (https://github.com/tessel/sdcard), and a FAT (https://github.com/natevw/fatfs) libraries albeit in JavaScript so it's familiar territory.

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 :-)

Post Reply