brain

Can someone confirm the recent master branch compiles and runs correctly on Arduino?

If you have the capability to compile the files, I can send the #define changes and you can give things a whirl in parallel.

As noted, some of the defines were not correct for the new PCB. Fixed that. But, still not working. Eventually, I moved back to the Arduino build, still not working. A few possibilities: a) my cc40 has hexbus issues (need to pull out a second unit) b) the current build has issues (need to roll back and try an older build) I'm going to try (b) first, as it's simpler, but time grew short in the evenings and this sort of debugging is not done well late at night when I'm tired. This weekend is a holiday one in US, and I've got some time with no interruptions this evening. Sunday as well. Jim

Working on it. PWR LED lights up, but only after I program. Tracking down the issue

I think the caps are 82pF, but I will check. Sreid specced those, from TI data sheets, but let me check my notes. C1/C2 are 18-22 pF, just like Arduino, if you select a 12-18pF parallel cap crystal. R1 is 10K (good catches, nag me to update the schem) The 7805 would actually be something like: https://www.digikey.com/en/products/detail/texas-instruments/LM2931AZ-5-0-LFT1/3640755 I think I just used the '05 footprint since it was handy. I'll check the Makefile for the fuses. Jim

No worries. Time grew short tonight to grab the PCB and try it out, but will do so MOnday evening. Yes, teh LED should light, so let me see if I have messed up the build. I focused my last attention on the Arduino build, and could have broken the regular one. Jim

Hmm, I thought I wrote somewhere that they have to be .8mm-1.0mm to fit. I'll have to add it. Feel free to pull and merge some text in the README.md file DId you try to program the files from the https://github.com/go4retro/HEXTIr/tree/master/obj-m328 directory? The single PCB design I have in there is different from the Arduino configs. Also, which PCB design did you use? v1 or v1.1? Jim

I'd check with the person you bought it from. Most of them are Arduino-based, so you'd need to run the Arduino IDE and load in a new copy. Let me see if I can get unpacked from the recent expos and duplicate the issue

At this point, you can only use the card as a 32kB RAM expansion. Until someone writes code to use the 2 software banking bits, only the 32kB will be useful. Thanks for testing. i will update the schematic to utilize only a 128kB SRAM and remove the DIP switches.

If the cc40 resets every time, you can't use it all. I designed the cart, but I relied on others to test it. It appears no one tried to use more than 32kB (the design should allow 32kB at once). But, before we write it off, I think someone should test restarting the cc40 16 times, once for each DIP switch setting. Then, try to switch back to one of the previously set banks and see if it still resets. If it does not, then the 16 times of resetting is to "format" all of the banks. If it resets every time, even after the 16 "formats", then the best the cart can do is 128kB, with the jumpers on the back, but I don't think the internal OS uses the paging bits, so the extra RAM would only be usable with special programs.

The 512kB cart does not use the paging lines for anything, though you can close some jumpers on the back (P25.2 and P25.3) to enable the paging bits to be used to select which of 4 banks of 32kB can be used at any time. The two lines override the first 2 switches of the 4 switch selector. Thus, the switches need to be "off" for this to work. TO be fair, I created the RAM cart from the ROM cart design, adding in the pieces from the original RAM cart design for battery backup. But, the original RAM cart I think was just 32kB, so did not bank. I created the design as a 512kB design since the ROM cart used the 512kB size, and the AS6CX008 came in various sizes, including the 128kB SRAM option that would be of use if the paging bits were leveraged. So, it might be that 128kB is the largest RAM really usable. Jim

I think we may be looking at the wrong schematic. HM61256 is an SRAM IC, so that schematic matches the CC RAM Cart (there's no battery backup on this cart, but that's easy to just not stuff those components). I think the cc40mech.pdf is the correct file to use, if the full ROM is 64kB is since. The multi-cart only banks on 32kB images, and that's a 64kB image. The fix would be as simple as leaving the switch 1 off, and putting a jumper wire from the 3rd pin from the left (under the PCB) to A15 on the ROM. Here is a pic: The edge pin needed is the one *under* the PCB (bottom side), and the wire can be connected to any of the 3 pads circled at the top right of the PCB. All can be done on the bottom side of the PCB. I would then load the image up as many times as will fit in the ROM, burn it, and try.

I would. Using the pin numbers on those schematics would truly trash a cc-40

OK, done. FYI: https://discord.gg/pkPfdBR

The multi-cart already has this in place. Notice pins 35 and 21 on the cart are tied together: https://github.com/go4retro/CC40_ROMCart/blob/master/pcb/CC40 ROM Cart PCB.png pin 39 is what we used to call pin 20 (Vplug) I think there is another issue, as the CS stuff is correct. I think it's already there. I guess, show me where I am mistaking things. I'll look at this, and see what it is doing. I think this is just due to A14 being inverted on the address lines.

I'm happy to help, but I am confused. The schematics show D0 on 22, but the materials I saw have it on pin 40. D7 is shown on 14 but is actually on 34 on reference docs. I know TI named lines backwards, but none of the data line numbers match up, nor do address lines. I'm leery of modifying until I can reconcile. I *think* the conversion is: (01) 1 GND (40)21 !CS_CROM (03) 2 Vbatt (38)22 A6 (05) 3 P25.2 (36)23 A5 (07) 4 A9 (34)24 A4 (09) 5 A11 (32)25 A2 (11) 6 !OE (30)26 A0 (13) 7 !RESET (28)27 GND (15) 8 INT3 (26)28 D2 (17) 9 CLKOUT (24)29 D1 (19)10 R/!W (22)30 D0 (21)11 !ENABLE (20)31 D6 (23)12 !A14 (18)32 D5 (25)13 ALATCH (16)33 D4 (27)14 D3 (14)34 D7 (29)15 A1 (12)35 !CS_CRAM (31)16 A3 (10)36 A10 (33)17 P25.3 (08)37 A8 (35)18 A12 (06)38 A15 (37)19 A7 (04)39 !WE (39)20 Vplug (02)40 A13 Which is wild and horrific, but it seems the match up. But, if so, then CS_CRAM and CS_CROM are mapped this way already in the cart, with the 3K3 resistor.

Ooh, I'll watch the store. I have a modem interface, but am looking out for other items to ensure HEXTIr emulation compatibility. I'm glad to see someone grabbed the 18K unit. I was interested, but $325.00 is a bit pricey for my blood. Jim

Hopefully someone can put the missing ones into the archive CC-40 cartridges.zip

Why does the chess file need to be loaded into memory? Can't you just open the file for reading and just read data until a CR or LF and then process the single move? That way, files up to the size of the drive in use (8050/8250/sfd1001/X040) Jim

Updated Ed Hallett cartridge port map: ============================================================================ CC-40 CARTRIDGE PORT PINOUT: TOP |---------------------------------------------------------------| E | 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 | D | | G | 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 | E |---------------------------------------------------------------| ____ __ 1 GND 21 CROM [ CS ] 2 +5 VOLT CONSTANT 22 A6 3 UNKNOWN (LOW) [ P25.2 ] 23 A5 4 A9 24 A4 5 A11 25 A2 ______ __ 6 DELAYED ALATCH + READ [ OE ] 26 A0 _____ 7 RESET 27 GND ____ 8 INT3 28 D2 9 CLKOUT 29 D1 _ 10 R/W 30 D0 ______ 11 ENABLE 31 D6 ___ 12 A14 32 D5 13 ALATCH 33 D4 14 D3 34 D7 ____ __ 15 A1 35 CRAM [ CS ] 16 A3 36 A10 17 UNKNOWN (LOW) [ P25.3 ] 37 A8 18 A12 38 A15 __ 19 A7 39 UNKNOWN (PULSE) [ WE ] 20 +5 VOLT SWITCHED 40 A13 =========================================================================== CC-40 CARTRIDGE PORT SIGNALS: SIGNAL DESCRIPTION ALATCH Logic 1 while port C (multiplexed address/data bus) asserts a memory address. R/W Logic 1 for read cycle, logic 0 for write cycle. ______ ENABLE Logic 0 for external (off processor) memory cycle. CLOCKOUT Output clock for memory control timing. A0 - A7 Addresses A0 thru A7 demultiplexed from D0/A0 thru D7/A7 signals. D0 - D7 Multiplexed data lines D0/A0 thru D7/A7. ____ CRAM Logic 0 for memory bank 5000-8FFF enable. ____ CROM Logic 0 for memory bank 9000-CFFF enable. ____ INT3 Logic 0 to initiate a level 3 interrupt. _____ RESET Logic 0 to initiate a level 0 interrupt (RESET). DELAYED ALATCH+READ Logic 0 for one time state immeadiately following the ALATCH signal return to logic 0 when R/W(NOT) is logic 1. (Most likely used for memory address timing control) =========================================================================== Accessing it via assembly for the most part is just like normal RAM/ROM. The P25.2 and P25.3 bits are in a register, but someone else will need to provide that.

I know I'm guilty of this, posting again and again in this thread, but we really need to tie off this discussion 🙂 To the OP: Everyone agrees the built in apps sucked. It's not really the fault of the devs, as they had perfectly good versions that sold well. The cost reductions and constraints so indicative of Commodore forced 64kB of apps to be squeezed (badly) into 32K. But, it did not matter in the slightest. No one seriously used these apps, for the reasons discussed (lack of tape, forcing the drive to be purchased, and if you had the drive, you would buy a better app, the aforementioned squeeze created so many limits, etc.) Pure and simple, the 3+1 was a marketing gimmick, and the fact that the apps worked at all meant that buyers could not sue Commodore. And, to be fair, it was a good gimmick. I don't recall too many other PCs at the time that had built-in apps that were not portable (Tandy M100 did, the various pocket PCs did, but they were typically more expensive, limited GFX/text, and were often purpose-driven. A bog standard home computer with built-in apps probably grabbed people's attention ("Hey, let's buy this one, it comes with free apps!"). Lack of cassette support? Sir, this is a productivity app. That is disk drive territory. Oh, and we have a tweaked version of our 1541 that's way faster (and more expensive and less compatible with our older machines...) Horrid document length limits? Sir, this is the basic version of the app, used for the quick notes and memos. You writing a novel? We have EasyScript/+4 (and a drive) for you! Add to the list (in your head) as you see fit. I guess my overall point is that, at least with CBM, it's easiest to walk backwards from the financials. CBM wanted to sell a bunch of machines, sell them cheap, and open up a way to force consumers to re-buy the apps they already owned (and buy all new peripherals as well). Marketing got involved. 3+1 got ideated, done. Jim

Sadly, a straight conversion is probably not effective. Initial tests a few years back with an esp32 yielded poor results. I wrote some new HEX support code that ran on the esp32, but required additional ICs to handle the low latency HSK handling needed by the protocol. The transition from HSK(master) LO to HSK(peripheral) LO must be done in 8uS or less. TO be safe, 7uS is effective max. AVR can handle that no problem, since it is single task, but esp32 running FreeRTOS was showing me 9uS or longer latency. Removing FreeRTOS slid it down to 2-3uS, but then you lose all of the cool things like Wifi and such, since they require FreeRTOS. That said, I think it depends somewhat on what types of output is desired. Little LCD panels are fine with the Arduino or esp32, and it looks like esp32 can do VGA, but if HDMI or something is needed, I'm not sure the esp32 is the best target. It's probably best to move the discussion over the dedicated video thread: Jim

Thanks. I did a check before asking, but did not see this. Jim

I think it's important to remember in the early years, there was little consensus on what consumers wanted. Though the SX64 was a gamble, CBM could have had a hit on their hands (and they do now, as the devices are coveted, but 30 years too late :-). The +4 was a gamble as well, and to your point early in the thread, if Jack was truly attempting to kill the ZX81 with a low cost rival, there's no guarantee the original C116 concept coming to all markets would have assured that. They recovered the fumble a bit with the C128, at least to have a low end product in the marketplace. The Amiga took over the mid and higher end of the range, and they had significant success there for at least a half decade.

I tried some 8266s here, but prefer the esp32. Is there an Uno-compatible esp32 board? Jim