Expansion bus

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice. No drama.
User avatar
marcelk
Posts: 488
Joined: 13 May 2018, 08:26

Re: Expansion bus

Post by marcelk »

I just found and fixed the issue in CardTest.gcl. It turned out to be a one-character typo that has always been in there. Depending on where the file is placed it may or may not trigger.

The current revision walks through the root directory and lists the entries it finds. Once it sees BOOT.GT1 it stops to load and execute that. You'll need the latest dev.rom to get CardTest to work. And the card must be formatted as FAT32.

It's tests ok now with HelloWorld.gt1 (small single sector file) and MSBASIC.gt1 (multi sector, multi cluster file). This brings us one step closer to a little command line tool. However, GT1 files that preload constants into zero page still can't be loaded, because now CardTest still uses an awful lot of it for itself. This will change for the better along the way. For example, the entire directory listing part can become a program by itself ("Dir.gt1"...), shrinking CardTest considerably.
User avatar
marcelk
Posts: 488
Joined: 13 May 2018, 08:26

Re: Expansion bus

Post by marcelk »

As of yesterday, DEVROM itself can detect a memory card during reset. When detected it will continue to boot from there instead of jumping to the built-in main menu. This means you don't need the Arduino route anymore when playing with the expander.

Naturally everything still needs refinements. But from here we can theoretically bootstrap an entire new system without ever updating the EPROM again, and without being tethered to a laptop/PC.

Some unrelated but noteworthy recent updates:
  • Preliminary interrupt support is now available (vIRQ)
  • We have the ROM files discoverable with a new function: SYS_ReadRomDir. With this we can iterate over the built-in files and get their ROM address for reading. I can see this become useful in a simple command line shell. Or for making libraries.
  • TinyBASIC now accepts hexadecimal numbers ($....) in expressions. This could be squeezed in without sacrificing free bytes.
User avatar
vk2
Posts: 3
Joined: 15 Jul 2018, 20:49

Re: Expansion bus

Post by vk2 »

Hi, I'd like to build expansion bus, but I'm little confused - where is the latest PCB/BOM files? (seems it's scattered over the messages). Thanks in advance.
User avatar
marcelk
Posts: 488
Joined: 13 May 2018, 08:26

Re: Expansion bus

Post by marcelk »

We keep all hardware related stuff in this thread. For the board I'm now playing with there's a schematic earlier in this thread + notes on how to patch it. I searched my folders and I believe the CAD files are those attached here:

Expansion 1906.zip
(545.76 KiB) Downloaded 433 times

I actually continued the CAD from there, but my current schematic and layout don't match. I can finish it when I make new hardware, and for that the software must goes first. (We need a bit more evidence that the pull-down resistors will work with all SD cards.)

I also still have one or two boards available to those interested. They need patching as described earlier in this thread.
User avatar
Marco
Posts: 24
Joined: 08 Dec 2019, 15:33

Re: Expansion bus

Post by Marco »

marcelk wrote: 27 Dec 2019, 21:19I also still have one or two boards available to those interested. They need patching as described earlier in this thread.
Hi Marcel,

I'm certainly interested! I can PM you (or PM me ;) ) if you have a board available.

Cheers,
Marco
xopr
Posts: 21
Joined: 05 Jun 2018, 12:05

Re: Expansion bus

Post by xopr »

vk2 wrote: 27 Dec 2019, 17:39 Hi, I'd like to build expansion bus, but I'm little confused - where is the latest PCB/BOM files? (seems it's scattered over the messages). Thanks in advance.
This topic indeed becomes a bit of a challenge to gather all important snippets from..
Here is a short summary to get on par (leaving SD/MMC parts out since it moved to here):

Apart from Marcel's attachment based on the revision 4 post you also need to apply some patch work to accommodate for the software optimization as followed:
  • U1 pin 3 --> J3 (A15-->MOSI)
  • U1 pin 4 --> U1 socket 13 (or J1 pin 10) (A0-->SCLK)
  • U1 socket 3 --> U1 pin 14 (A7-->B1)
  • U1 socket 4 --> U1 pin 13 (A6-->B0)
  • R1 change to 2k2
  • R1 pin 1 --> C3 south (GND)
If you're working with a rev.1909 (revision 4) board, these pictures in this post might be of some visual guidance.

Some extra remarks:
  • for J2, 0.47mm diameter connector pins play well with the Gigatron's RAM socket (example from Mouser )
  • I had to cut off a bit of J2 pins 4, 9 and 13 for the IC socket to fit snugly on top.
  • SPI headers will touch Gigatron's U29, U30, U32 and U33 if they were socketed
  • using a RAM socket will lift (and scratch) the lid
Arduino SPI remarks:
  • don't use Arduino's ICSP header since pin 5 is tied to reset and will crash/freeze the Gigatron: always use the shield header's SS (pin 10 on an Arduino Uno for proper SPI slave operation)
  • disable reset-on-serial (scratch solder jumper "Reset on") for reliable serial communication
:edit:
made a mistake, U1 pin 12 is untouched.
Also, update the information on Arduino SPI
Last edited by xopr on 16 Jan 2020, 14:26, edited 3 times in total.
User avatar
marcelk
Posts: 488
Joined: 13 May 2018, 08:26

Re: Expansion bus

Post by marcelk »

xopr wrote: 15 Jan 2020, 16:28
[*]don't use the ICSP header since SS is tied to reset and will crash/freeze the Gigatron
How does this issue occur? /SS is an output, and should always be driven by the host aka Gigatron. So I don't follow this exactly, and wonder if you have a schematic of what that ICSP header exactly does on this line? Is this something we should address on the Gigatron side?

I hoped that we had preempted any line contention and Gigatron crashes during reset by splitting the MISO lines. But if there are other scenarios, I like to be aware of them..


[P.S: I momentarily and accidentally "vandalised" your post by hitting the wrong button to reply. I just restored it. My apologies that it looked a bit funny for a few minutes.]
xopr
Posts: 21
Joined: 05 Jun 2018, 12:05

Re: Expansion bus

Post by xopr »

marcelk wrote: 15 Jan 2020, 20:17 How does this issue occur? /SS is an output, and should always be driven by the host aka Gigatron
....
Is this something we should address on the Gigatron side?
I might have to add that it is subject to the Arduino's reset pin on the ICSP header which I guess is not intended for SPI slave operation (you can find a pdf here; also not to be confused with ICSP1), but intended for programming the AVR;
It has a hard 'link' to the reset button(s) (0 ohms), and via a capacitor to DTR (can be disconnected via a scratch jumper)
Also, it is pulled up with 10k.

To be honest, I don't know what crashes the Gigatron; it might be a socket that is misbehaving on my side, but I can imagine that the AVR's programming sequence or its floating (pulled up) SS connection conflicts with the Gigatron.

Either way, it works fine if you don't use ISCP pin 5, but shield header pin 10.
I was a bit out of the running (quite literally) lately, but if you want, I could try some additional testing with the Arduino..
:edit:
I've updated the original post a bit so it's less confusing (I hope; I used the wrong terminology)
jwolfram
Posts: 18
Joined: 07 Jan 2019, 20:11

Re: Expansion bus

Post by jwolfram »

Last weekend I tried to implement the SPI routines tom my "Micro-" Emulator. Everything seems to work, but I'm no able to get my SD card working. It is a 2GB SD-Card (not SDHC), formatted with fdisk and mkfs.vfat -F 32. But I get always "Vol.ID 0000 Failed".
Is there a special treatment to get this card to work?
Attachments
gt_sd1.jpg
gt_sd1.jpg (185.85 KiB) Viewed 8129 times
User avatar
marcelk
Posts: 488
Joined: 13 May 2018, 08:26

Re: Expansion bus

Post by marcelk »

That's more than likely the same software issue mentioned in the GTOS thread:
https://forum.gigatron.io/viewtopic.php?p=1215#p1215
I haven't found time to dive into it yet...

[Edit: created GitHub issue: https://github.com/kervinck/gigatron-rom/issues/161]
Post Reply