+acadiel Posted April 6, 2020 Share Posted 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. 1 Quote Link to comment Share on other sites More sharing options...
+acadiel Posted April 6, 2020 Share Posted 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 Quote Link to comment Share on other sites More sharing options...
brain Posted April 6, 2020 Share Posted April 6, 2020 Yes, that is correct. Maybe add that to the pull request Quote Link to comment Share on other sites More sharing options...
+acadiel Posted April 6, 2020 Share Posted April 6, 2020 (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 April 6, 2020 by acadiel Quote Link to comment Share on other sites More sharing options...
brain Posted April 6, 2020 Share Posted 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); } Quote Link to comment Share on other sites More sharing options...
+acadiel Posted April 6, 2020 Share Posted 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? Quote Link to comment Share on other sites More sharing options...
brain Posted April 6, 2020 Share Posted 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 Quote Link to comment Share on other sites More sharing options...
+acadiel Posted April 6, 2020 Share Posted April 6, 2020 (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: 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 1 Quote Link to comment Share on other sites More sharing options...
wierd_w Posted April 7, 2020 Share Posted 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. Quote Link to comment Share on other sites More sharing options...
brain Posted April 7, 2020 Share Posted 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 Quote Link to comment Share on other sites More sharing options...
+acadiel Posted April 7, 2020 Share Posted 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. 1 Quote Link to comment Share on other sites More sharing options...
wierd_w Posted April 7, 2020 Share Posted 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. 1 Quote Link to comment Share on other sites More sharing options...
brain Posted April 7, 2020 Share Posted April 7, 2020 I was looking at the specs as defined on the HexBus stuff and determining how to implement from that. Jim 1 Quote Link to comment Share on other sites More sharing options...
wierd_w Posted April 7, 2020 Share Posted April 7, 2020 (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 April 7, 2020 by wierd_w Quote Link to comment Share on other sites More sharing options...
brain Posted April 10, 2020 Share Posted 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. Quote Link to comment Share on other sites More sharing options...
brain Posted April 10, 2020 Share Posted April 10, 2020 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+acadiel Posted April 10, 2020 Share Posted 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. Quote Link to comment Share on other sites More sharing options...
+acadiel Posted April 10, 2020 Share Posted 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. Quote Link to comment Share on other sites More sharing options...
brain Posted April 10, 2020 Share Posted 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. Quote Link to comment Share on other sites More sharing options...
+acadiel Posted April 10, 2020 Share Posted 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? Quote Link to comment Share on other sites More sharing options...
brain Posted April 10, 2020 Share Posted 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 Quote Link to comment Share on other sites More sharing options...
+acadiel Posted April 10, 2020 Share Posted 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 1 Quote Link to comment Share on other sites More sharing options...
brain Posted April 10, 2020 Share Posted 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? Quote Link to comment Share on other sites More sharing options...
+acadiel Posted April 10, 2020 Share Posted 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. Quote Link to comment Share on other sites More sharing options...
brain Posted April 10, 2020 Share Posted 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.