The Compact Computer 40 (CC40)

+acadiel · April 6, 2020

jon@X390 MINGW64 /d/dev
$ avrdude -v -V -carduino -patmega328p -C"C:\Program Files (x86)\Arduino\hardware\tools\avr\etc\avrdude.conf" -PCOM4 -b115200 -D -Uflash:w:HEXTIr.bin

avrdude.exe: Version 6.3-20190619
             Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
             Copyright (c) 2007-2014 Joerg Wunsch

             System wide configuration file is "C:\Program Files (x86)\Arduino\hardware\tools\avr\etc\avrdude.conf"

             Using Port                    : COM4
             Using Programmer              : arduino
             Overriding Baud Rate          : 115200
             AVR Part                      : ATmega328P
             Chip Erase delay              : 9000 us
             PAGEL                         : PD7
             BS2                           : PC2
             RESET disposition             : dedicated
             RETRY pulse                   : SCK
             serial program mode           : yes
             parallel program mode         : yes
             Timeout                       : 200
             StabDelay                     : 100
             CmdexeDelay                   : 25
             SyncLoops                     : 32
             ByteDelay                     : 0
             PollIndex                     : 3
             PollValue                     : 0x53
             Memory Detail                 :

                                      Block Poll               Page                       Polled
               Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
               ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
               eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
               flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
               lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
               hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
               efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
               lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
               calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
               signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

             Programmer Type : Arduino
             Description     : Arduino
             Hardware Version: 3
             Firmware Version: 4.4
             Vtarget         : 0.3 V
             Varef           : 0.3 V
             Oscillator      : 28.800 kHz
             SCK period      : 3.3 us

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude.exe: Device signature = 0x1e950f (probably m328p)
avrdude.exe: reading input file "HEXTIr.bin"
avrdude.exe: input file HEXTIr.bin auto detected as raw binary
avrdude.exe: writing flash (12358 bytes):

Writing | ################################################## | 100% 1.98s

avrdude.exe: 12358 bytes of flash written

avrdude.exe done.  Thank you.

Looks like it worked! Going to go try it.

+acadiel · April 6, 2020

@brain - in this document:

https://github.com/go4retro/HEXTIr/blob/master/doc/arduino/Assembly Instructions.txt

Do you mean to increment the data pins? i.e.

HEX D0 -> A0

HEX D1 -> A1

HEX D2 -> A2

HEX D3 -> A3

At least, that's what I'm assuming

brain · April 6, 2020

Yes, that is correct. Maybe add that to the pull request

+acadiel · April 6, 2020

11 minutes ago, brain said:

Yes, that is correct. Maybe add that to the pull request

One final question - what is the behavior of the L1 LED supposed to be? Which device # does this respond to?

About to go hook it up to my CC-40 now that I verified the pins were correct. Will also try on the 74.

Edited April 6, 2020 by acadiel

brain · April 6, 2020

The unit responds by default on #100

The LED does double duty. When on, it means file is open. When flashing, it means an error has occurred. The unit has code to set the device # from 100-107:

static inline uint8_t device_hw_address(void) {
return 100 + !((PIND & (_BV(PIN4) | _BV(PIN5) | _BV(PIN6))) >> 4);
}

+acadiel · April 6, 2020

4 minutes ago, brain said:
The unit responds by default on #100

The LED does double duty. When on, it means file is open. When flashing, it means an error has occurred. The unit has code to set the device # from 100-107:
static inline uint8_t device_hw_address(void) {
return 100 + !((PIND & (_BV(PIN4) | _BV(PIN5) | _BV(PIN6))) >> 4);
}

Gotcha, thanks! I have it hooked up, and the Arduino power light is on - L1 is not. I've double checked my pinouts by hooking a Hexbus cable to a CC-40 and oriented both devices the same way to verify the 8 pins orientation were correct. I've double checked the pins, the 1GB SD card is formatted FAT32, and the tab is set to allow writes.

The CC-40 does power up with the device attached; however, any time I try to save "100.FILE", I don't get any response (just an I/O 255 error.) I've tried a couple different FAT32 SD cards. Since I've triple checked the wiring, it might be the way I compiled it or programmed the Uno, since I'm not seeing any activity on it at all when I try to complete Hexbus saves. I'm assuming I don't need the Hexbus format command.

Thoughts?

brain · April 6, 2020

Sounds like some debugging is in order. I can put my kit together again, but it'll be a few days. If the arduino uses the USB as a serial port (I think it does), then you might be able to use the built into UART code in the prj to sniff out what is going on when the save is requested. BAV should go low, as I recall, and HSK should then almost immedaitely go low to ack the request. It sounds like that is not happening.

Jim

+acadiel · April 6, 2020

17 minutes ago, brain said:

Sounds like some debugging is in order. I can put my kit together again, but it'll be a few days. If the arduino uses the USB as a serial port (I think it does), then you might be able to use the built into UART code in the prj to sniff out what is going on when the save is requested. BAV should go low, as I recall, and HSK should then almost immedaitely go low to ack the request. It sounds like that is not happening.

Jim

No worries about timing.. this has been something on my workbench for a while.

The compile looks ok:

jon@X390 MINGW64 /d/dev/HEXTIr-master
$ ./make.exe CONFIG=config-arduino
  MKDIR  obj-m328p-arduino/src/
  CONF2H config-arduino
  CC     src/diskio.c
  CC     src/ff.c
  CC     src/hexbus.c
  CC     src/led.c
  CC     src/main.c
  CC     src/sdcard.c
  CC     src/spi.c
  CC     src/timer.c
  CC     src/uart.c
  CPP    config.h
  AS     src/crc7asm.S
  LINK   obj-m328p-arduino/HEXTIr.elf
  BIN    obj-m328p-arduino/HEXTIr.bin
  HEX    obj-m328p-arduino/HEXTIr.hex
  SIZE   obj-m328p-arduino/HEXTIr.elf
obj-m328p-arduino/HEXTIr.elf  :
section                      size      addr
.data                          14   8388864
.text                       12344         0
.bss                          878   8388878
.stab                         204         0
.stabstr                       58         0
.comment                       17         0
.note.gnu.avr.deviceinfo       64         0
Total                      101941

I looked at the debug statement for the Arduino for when it programs, and just tried programming it with the same syntax (I did this one on the Windows command line):

"C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avrdude" -C"C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf" -v -patmega328p -carduino -PCOM4 -b115200 -D -Uflash:w:D:\dev\HEXTIr.hex:i


avrdude: Version 6.3-20190619
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf"

         Using Port                    : COM4
         Using Programmer              : arduino
         Overriding Baud Rate          : 115200
         AVR Part                      : ATmega328P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : Arduino
         Description     : Arduino
         Hardware Version: 3
         Firmware Version: 4.4
         Vtarget         : 0.3 V
         Varef           : 0.3 V
         Oscillator      : 28.800 kHz
         SCK period      : 3.3 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: safemode: lfuse reads as 0
avrdude: safemode: hfuse reads as 0
avrdude: safemode: efuse reads as 0
avrdude: reading input file "D:\dev\HEXTIr.hex"
avrdude: writing flash (12358 bytes):

Writing | ################################################## | 100% 2.38s

avrdude: 12358 bytes of flash written
avrdude: verifying flash memory against D:\dev\HEXTIr.hex:
avrdude: load data flash data from input file D:\dev\HEXTIr.hex:
avrdude: input file D:\dev\HEXTIr.hex contains 12358 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 1.99s

avrdude: verifying ...
avrdude: 12358 bytes of flash verified

avrdude: safemode: lfuse reads as 0
avrdude: safemode: hfuse reads as 0
avrdude: safemode: efuse reads as 0
avrdude: safemode: Fuses OK (E:00, H:00, L:00)

avrdude done.  Thank you.

No change.

I'll be glad to help debug when you get everything setup again, please let me know. Thanks a bundle for all your replies today!

p.s. tested for shorts too....

Edited April 6, 2020 by acadiel

wierd_w · April 7, 2020

Do we know anything about the video controller's data formats?

This seems like it would be a great application for a Pi Zero.

brain · April 7, 2020

9 hours ago, wierd_w said:

Do we know anything about the video controller's data formats?

This seems like it would be a great application for a Pi Zero.

The cc40 is emulated, I thought. That would give video controller data

Jim

+acadiel · April 7, 2020

27 minutes ago, brain said:

The cc40 is emulated, I thought. That would give video controller data

Jim

I think wierd_w is talking about this.

I know of only one person that has this. The other one was sold on eBay a few years ago when Michael Becker emptied his magic basement. Ksarul or Atrax likely knows who purchased it - the purchaser has been silent and never came forward.

wierd_w · April 7, 2020

acadiel is correct-- that is the beast I was referring to.

As far as I know, only engineering samples like that one existed. However, clearly-- that work WAS done. I would very much like to have somebody that has one do some logic analyzer magic of the hexbus for it, and drop us a present.

A Pi-Zero has video out (or at least, pins for video out), and sufficient PWM capable GPIOs to do the task. Its only downside would be the slow power-on time. It could be a one-stop-shop for video out, data storage, and print brokering for a CC-40 though. The printer data messages are more or less known, (iirc), but the video output messages are not.

brain · April 7, 2020

I was looking at the specs as defined on the HexBus stuff and determining how to implement from that.

Jim

wierd_w · April 7, 2020

If I were going to roll my own, I would go with something similar to the original X window specification, at least conceptually.

X protocol is too heavy for the CC40, but something "like" it could be implemented. The CC40 would give an abstract "event" instruction to the video device, which would then do all the heavy lifting. I was thinking something like:

Define (Send a nibble indicating the kind of define [Foreground/Background color], [Palette entry], [Character ID + Bitfield data], etc..)
Event (Send a keypress event character ID, with a cursor Row & Column)

Clear (Instruct the video terminal to clear all rows and columns/blank a layer)

Error (Return either a success message, or a failure message with a failure ID value.)

That would be pretty lightweight, but would allow a surprising amount of graphics capabilities in a more or less high level fashion.

Define message could also contain individual pixels, or abstract draw instruction (like Circle, Line, Fill, etc.), or even which layer to draw on. If you abused openGL in the zero, you could do something kinda like hardware sprites as well.

Basically, Allow for multiple and overlapping layers that can each be individually drawn on with events, by first sending a define to state what layer you want to draw on. Each layer would be essentially 1bpp, and would have a foreground color and background color attribute. Layer 0 is special, in that its background color is actually the background color. All subsequent layers would have the bg color transparent. Perhaps, say-- 16 such layers? Then drop on OpenGL 2-triangle polygons with textures on them, and pretend those are hardware sprites. Have them float above the dumb raster layers.

That would allow for some very pretty graphics to be output, and reasonably quickly. (An initial databurst from the CC-40 would define all the characters, then all the palette colors for the layers, then any sprites. After that, the CC40 draws all the needed characters on the screen on the appropriate layers.

HOWEVER--

For preservation and historicity, I would like to implement whatever was inside those engineering samples. I dont know how TI did it.

Edited April 7, 2020 by wierd_w

brain · April 10, 2020

OK, good news is that I get the same behavior on Arduino.

Bad news is that I get the same behavior on Arduino (no workie).

Debugging now.

brain · April 10, 2020

I had the HSK signal on the wrong pin. Working now.

Let me look at your pinout.

It looks like you have your top row of HEXbus and bottom row of hexbus switched around (and D2/D3 swapped). looking at the underneath of your board, you have (L-R) (on top row): HSK, BLANK, D3 D2 and (bottom row) D0, D1, BAV,GND.

But, you have have (L-R) Top: D0, D1 BAV, GND and Bottom: HSK, BLANK, D2, D3

Try that.

Edited April 10, 2020 by brain

+acadiel · April 10, 2020

6 hours ago, brain said:

I had the HSK signal on the wrong pin. Working now.

Let me look at your pinout.

It looks like you have your top row of HEXbus and bottom row of hexbus switched around (and D2/D3 swapped). looking at the underneath of your board, you have (L-R) (on top row): HSK, BLANK, D3 D2 and (bottom row) D0, D1, BAV,GND.

But, you have have (L-R) Top: D0, D1 BAV, GND and Bottom: HSK, BLANK, D2, D3

Try that.

Looking straight at my Hexbus connector (female cable that connects to the board)

	      __
       ______|	|______
      |                | 
      |   4  3  2  1   |
      |                |
      |   8  7  6  5   |
      |----------------|  

(top row)
1 GND - Arduino GND
2 BAV - Arduino 7
3 D1 - Arduino A1
4 D0 - Arduino A0
(bottom row)
5 D2 - Arduino A2
6 D3 - Arduino A3
7 N/C
8 HSK - Arduino 3

The problem is that there's no solid reference for the numbering as well as male vs. female - vs. way you're looking at the connector. To me, the top row of the Hexbus connector is the one with the notch.

+acadiel · April 10, 2020

Just a further set of troubleshooting... I made an 8 pin female to (2) four pin females and tried flipping over the top and bottom connectors (to where they went right to left instead of left to right). I went inside the CC-40 and touched GROUND to the GND on the Arduino and there's connectivity. Right below GND is the D2 pin, which does go to A2 on the Arduino. So, I know the orientation is correct.

SAVE "100.FILE" keeps giving me I/O error 255 on device 100.

I do notice that if I withhold power from the Arduino that the IO indicator stays on the CC-40. the IO indicator on the CC-40 does also briefly light up on power up.

brain · April 10, 2020

On the chance it's a code issue, I put my working bin and hex file at http://www.go4retro.com/downloads/HEXTIr. Try those. If they do not work, I'll just pack up my unit and mail it to you, so you can mix and match and see what is going on.

+acadiel · April 10, 2020

18 minutes ago, brain said:

On the chance it's a code issue, I put my working bin and hex file at http://www.go4retro.com/downloads/HEXTIr. Try those. If they do not work, I'll just pack up my unit and mail it to you, so you can mix and match and see what is going on.

Yours flashed just fine - but still same result.

Another question: The SD card - does it need to be formatted in FAT or FAT32?

brain · April 10, 2020

Mine is FAT32, since it's a larger card. I tried a freshly formatted FAT32 card, with good results.

One thing you can try is running a terminal app and selecting the COM port of your Arduino @ 57600 bps. Reset the Arduino. You should see:

Mount SD RC: 00
Device ID: 0x64

If not, then we have other issues.

Jim

+acadiel · April 10, 2020

6 minutes ago, brain said:

Mine is FAT32, since it's a larger card. I tried a freshly formatted FAT32 card, with good results.

One thing you can try is running a terminal app and selecting the COM port of your Arduino @ 57600 bps. Reset the Arduino. You should see:

Mount SD RC: 00
Device ID: 0x64

If not, then we have other issues.

Jim

Yep, I see that on the com port when I boot it up. I also see a bunch of %ff's scroll when I try to do a SAVE or OLD From the TI-74 (or CC-40).

Just for troubleshooting, I hooked my Hexbus cable to my 8pin to 10pin Dockbus adapter and hooked the TI RS232 up to the 74, and ran a BASIC program to print "HIHIHI" to the 20 device. The PC terminal emulator saw it fine; so I know the Hexbus cable as well as the 8-10 pin adapter is working well. When I hooked the Arduino up to the same 8-10 pin Dockbus adapter (and reversed the top four pins and then bottom four pins because of my pinout difference), still no joy at SAVE "100.FILE". Tried formatting the SD with FAT and FAT32.

I'm sure it's something stupid. LOL

brain · April 10, 2020

41 minutes ago, acadiel said:

Yep, I see that on the com port when I boot it up. I also see a bunch of %ff's scroll when I try to do a SAVE or OLD From the TI-74 (or CC-40).

Hmm, that is odd. Just %ffs? Any chance I could see the output?

+acadiel · April 10, 2020

51 minutes ago, brain said:

Hmm, that is odd. Just %ffs? Any chance I could see the output?

Yup, here you go. Best I could get after I reset it.

brain · April 10, 2020

PM me an address and I'll send my entire unit. You can mix and match and see what is going on.

Jim

The Compact Computer 40 (CC40)

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Recently Browsing 0 members