Jump to content
sparkdrummer

The Compact Computer 40 (CC40)

Recommended Posts

[email protected] 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.

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)
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 by acadiel

Share this post


Link to post
Share on other sites

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);
}

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites
Posted (edited)
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:

 

[email protected] 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.... 

 

1BA3168B-C0DF-4DB1-B640-660B28EE8DDC.jpeg

9B1ECEA7-19DC-4D8D-89A8-C9B6DE666129.jpeg

Edited by acadiel
  • Like 1

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

 

 

 

videoback.jpeg

videofront.jpeg

  • Like 1

Share this post


Link to post
Share on other sites

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.

 

 

  • Like 1

Share this post


Link to post
Share on other sites

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

 

Jim

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)

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 by wierd_w

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by brain

Share this post


Link to post
Share on other sites
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.  

Share this post


Link to post
Share on other sites

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.

 

 

 

 

 

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

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

 

 

 

Share this post


Link to post
Share on other sites
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

 

 

 

 

  • Like 1

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

4067B06F-5AFA-4B3C-8345-357E54BCCA1C.jpeg

Share this post


Link to post
Share on other sites

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

 

Jim

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...