The Compact Computer 40 (CC40)

[+Vorticon]

On 8/26/2020 at 8:27 AM, dhe said:

Vorticon,
If you can let me know the upgrade procedure, that would be most helpful.
Thanks,
Dan

Hi Dan.

1. Download the attached zip file and extract it somewhere.
2. Start up your Arduino IDE, connect the Arduino Uno making sure you've got the proper COM port configured in the IDE
3. Load the src.ino file from the src directory in the file you just downloaded.
4. Press CTRL-U and it will compile and transfer the binary to the Arduino. You might get a low memory message which you can safely ignore. If you get an error pointing at the DS32xx line, you will need to go into the IDE under under Tools --> Manage Libraries and search for the appropriate DS32xx file and install it. Restart the IDE and the process should work now.
5. Install a FAT32 formatted SD card into the Arduino SD shield, connect the Arduino to your CC40, power it up first then the CC40 and off you go

Hopefully this helps.

 

HEXTIr-libmerge.zip

[brain]

Actually, with the new 'libmerge' codebase, no arduino libraries are used, so no errors about missing a DS3231 library (won't hurt if you dload or add it, but it won't be used).

[+arcadeshopper]

Is there any hardware change he needs to do too? His drive is the original from the pictures above

Sent from my LM-V600 using Tapatalk

[brain]

2 hours ago, Vorticon said:

Success! Works perfectly and passes the FOPSTEST. Nicely done

Whew! OK.  If folks here cna help with a quick "test the printer" and "test the serial port" programs, I will test those and if the code passes, I will merge this back into the main branch, which should bring us full circle, and then I'll make a release.

 

Jim

 

[brain]

1 minute ago, arcadeshopper said:

Is there any hardware change he needs to do too? His drive is the original from the pictures above

Sent from my LM-V600 using Tapatalk
 

If a previous sreid_mods Arduino sketch worked, then no HW mods are needed. 

 

The only mod I'm aware of of historical note is the switch of LED and BAV lines.  The repo has been updated the current preferred wiring, and I am trying to find a way to easily make a nice wiring diagram that shows the arduino itself and the SD card shield, so help folks.

 

All that said, if folks are making new units, Peter Engels (of TIIF2 fame), is now engaged on the project and he found that, under long periods of access (think, running the clock app and the program talks to the drive 2 times per second), the internal pullup resistors in the Arduino on the HexBus lines are just not enough to keep everything sane.  Through Stephen Reid (who works for TI and has added lots of functionality to the project, we've known for some time that the proper HexBus circuitry includes 6 8.2K ohm resistors on the 6 HexBus lines, pulled to 5V.  I also had included them (well, 10K) in my original HEXTIr PCB, but omitted them for the Arduino build, to save create time). Adding those makes for a more robust setup, so I'd include them (and will do so in the diagram I am making) in a new build.  But, the internal pullups are still enabled, so units with the resistors will still work (and, arguably, a proper clock app would not ping the drive RTC 120 times a minute.  It would read the clock and set an internal one, but the current app turns out to be a nice stress test for the unit).

 

Jim

 

[wierd_w]

Then all it needs, is some kind of abstracted display generator, and you have the full planned peripheral package.

 

Depending on the bandwidth, I would think something like X protocol would work.

[brain]

I went ahead and merged the code into master, and created a release (v.0.9.1.0).  I continue to test, so please open issues if anything is found.

 

Jim

 

[brain]

Release v0.9.1.2 is pushed to github: https://github.com/go4retro/HEXTIr/releases/tag/v0.9.1.2

 

• RTC year returned as 4 digits, and can be sent as 2 or 4 digits
• Spaces trimmed from front and back of received filename
• General code cleanup

Jim

 

Edited September 1, 2020 by brain
typo

[brain]

Release 0.9.1.3 is on github.

 

• Regression in saving larger files fixed
• hardware type 1 (non Arduino layout) compilation fixed
• I finally figured out how to make a bootloader work on the atmega328, so the bootloader can now update the code from the SD drive.

Jim

[brain]

Peter Engels has been working to enable all the DISPLAY and RELATIVE modes.  His work is in the pengels_mods branch, if folks want to try it.

[+Vorticon]

On 9/10/2020 at 8:15 PM, brain said:

Peter Engels has been working to enable all the DISPLAY and RELATIVE modes.  His work is in the pengels_mods branch, if folks want to try it.

What was the issue?

[+Vorticon]

On 9/1/2020 at 3:22 PM, brain said:

Release v0.9.1.2 is pushed to github: https://github.com/go4retro/HEXTIr/releases/tag/v0.9.1.2

 

• RTC year returned as 4 digits, and can be sent as 2 or 4 digits
• Spaces trimmed from front and back of received filename
• General code cleanup

Jim

 

RTC? Where would that come from?

[brain]

3 hours ago, Vorticon said:

What was the issue?

No issue, but the code didn't previously support RELATIVE files, and we switched DISPLAY files stored on disk to use CRLF has the line delimiter.  It makes it easier to edit with PC tools or load in files from other platforms.

Jim

 

[brain]

3 hours ago, Vorticon said:

RTC? Where would that come from?

Most of the SD card shields have a DS1307 RTC on board.  If yours does, pop in a battery and use.

 

jim

 

[+Vorticon]

6 hours ago, brain said:

Most of the SD card shields have a DS1307 RTC on board.  If yours does, pop in a battery and use.

 

jim

 

Ah got it. So how do you access the RTC time and date from the CC40? Can you set the clock from it as well?

[brain]

There's a clock.pgm and setclock.pgm apps int he BASIC folder that can be used to read and set the clock.

 

Jim

[+Vorticon]

8 hours ago, brain said:

There's a clock.pgm and setclock.pgm apps int he BASIC folder that can be used to read and set the clock.

 

Jim

Wonderful! That's nifty. 

[+Vorticon]

On 9/12/2020 at 10:29 PM, brain said:

There's a clock.pgm and setclock.pgm apps int he BASIC folder that can be used to read and set the clock.

 

Jim

Jim, do you have a listing for the clock program? I'm looking for the capability of reading the clock from within a Basic program instead of a standalone utility. This would be helpful for timing and such among other things.

[brain]

Right now, to keep the main branch in a nice working state, I've been checking the INTERNAL and such updates into the pengels_mods branch (which is working, and you can try it if desired.  I think Peter has all the file modes working quite correctly and he even implemented a special LUN [255] to allow folks to dump and read back binary images - which won't work with normal INTERNAL mode, as I understand).  Peter put Basic listings of all the apps in yesterday, so feel free to grab:

 

https://github.com/go4retro/HEXTIr/blob/pengels_mods/BASIC/CC40/CLOCK.B40

 

 

[+Vorticon]

Thanks!

Looking at the clock listing, I see that we are opening a file called "230" without a device prefix to get the clock reading. Is that the process?

Incidentally, I don't see any use documentation for any of these new features (Clock, LUN 255, Set Clock, directory) which obviously will not be in the CC40 manual. Are there plans to do so?

[brain]

1 hour ago, Vorticon said:

Thanks!

Looking at the clock listing, I see that we are opening a file called "230" without a device prefix to get the clock reading. Is that the process?

Incidentally, I don't see any use documentation for any of these new features (Clock, LUN 255, Set Clock, directory) which obviously will not be in the CC40 manual. Are there plans to do so?

I don't think any devices in cc40 have a prefix, all are numbers (100 -109 or so for drives, etc.).  230 is just an arbitrary number chosen for the RTC function, but it's not gospel, if there's a better number to use.

 

But, yes, the idea is to open, and any read will deliver the various parts of the date and time.  An open to write will set the date/time.

 

Given the nature as a hobby effort at present, I'll admit documentation is not a primary focus, but I agree there's value.

 

It'd be grand if there were one or more folks interested in helping with that effort, while we continue to add new features to the source

 

Jim

[+Vorticon]

59 minutes ago, brain said:

I don't think any devices in cc40 have a prefix, all are numbers (100 -109 or so for drives, etc.).  230 is just an arbitrary number chosen for the RTC function, but it's not gospel, if there's a better number to use.

 

But, yes, the idea is to open, and any read will deliver the various parts of the date and time.  An open to write will set the date/time.

 

Given the nature as a hobby effort at present, I'll admit documentation is not a primary focus, but I agree there's value.

 

It'd be grand if there were one or more folks interested in helping with that effort, while we continue to add new features to the source

 

Jim

So 230 is then the device number. Got it.

I'm happy to write a short usage document, but I first need to know how everything works. Can we clarify the usage of the LUN 255 feature?

 

[brain]

I'll try to have Peter write a little app to show how to use 255 (which is not set in stone, as we found a use case that makes 255 potentially better to send drive commands, so we might move it to 254).

 

Jim

 

[brain]

Peter says:

 

"RWRAM.B40/74/C40/74 allows to read/write/verify RAM/ROM 8/32k images. ROM is clearly r/o."

 

They would be in the same dir as the other BASIC programs I linked to.

[+acadiel]

Something to think about.

 

The Hexbus data pins were used to write to cassette on the TI-74.  The routines were in ROM on the 74 for this.  I wonder how easy it would be to create a small assembly routine to add the same cassette routines to the CC-40.  It's kind of an academic exercise because we have the SD card interface, but it would be fun to create a simple Hexbus cassette interface and an assembler routine you could put in RAM for cassette storage.  Unless this will only function as part of the CPU ROM.