brain

Well, yes, they all did. This one was CMOS, and I think derived from the Rockwell CMOS 65C02. 100% agree. We need to remember the now-coveted SX64 was pretty much a dud when it was introduced. Business users did not want a 40 column color PC, and the screen was bad, even then. For games, it was good enough, but for business, no go. And, the Venn Diagram of folks who wanted to play games and people who had enough money to buy the USD$595.00 SX-64 is almost a null set. Jim

Thanks. I think I fixed. Pull the tag again (or HEAD) and see if I fixed it for you. It was the weirdest include error I think I've seen so far. Oh well.

The Commodore LCD. It had little in common with the +4, different code, different CPU, different GFX, but it did leverage the +4 styling cues and the arrow cursor pad. Cute machine, and the apocryphal story is that CBM and Tandy were at a show where CBM told Tandy about the design, Tandy chided that such a thing would never sell. CBM went back and cancelled, Tandy went back and found a source for this great idea and made a pretty penny on sales. Probably not true, but cute story. Jim

Since the machine was supposed to be a "business" machine, disk restrictions make perfect sense to me. Jim

Can you share the error?

Your idea of simple and mine are vastly different. While I can design a 9118/9995 design, that's at least 5 ICs (those 2, some ROM, some RAM, and a glue CPLD) Expensive, uses NOS/hard to obtain parts, more expensive, and I'm not sure it really shows off the capabilities of eitehr vintage IC. It'd be period correct, but at that point, one might as well reverse engineer the original design and re-fabricate Fair, but you can implement the HexBus in a small CPLD and let the Pi or Pi Zero handle all the rest. The CPLD would only be needed for level shifting and handling the HSK pull down hardware assist. Yeah, it'd take a 144 for sure, and not sure that would even be enough. But, it somewhat depends on what type of device folks want. If portability is super important, the smaller screens and such are more important. If not, then the first attempt should be a Pi. One can always optimize down from there, or come up with an FPGA/Pi or FPGA centric option later. So, what size screen to people want 🙂

The ones I have here are 3.2" diagonal, 400x240. (Had to stop and refresh my Trig functions). 146DPI. @ 40 chars per line, each char would be 10 pixels wide, so 14 chars/inch. Tiny. eBay has Arduino shield-based panels for USD$12-15. I suppose it's a primary design decision to discuss first. The above panels are cheap and portable, but tiny. I'm not sure going up by an inch or two will make much difference, as the text would still be tiny. Thus, it seems the next logical size would be 8-12" diagonal, where chars would be 1/4" wide, roughly. Much easier on the eyes, but hardly portable. And, if that's the path, probably the best, cheapest, and most flexible option is to put a hat on a RPi/RPi Zero and use the HDMI out to a favorite display. I can see value either way. I suppose it depends on how portable folks want to be. Jim

So, it turns out the HX1100 was only 40x24. That makes the lcd panel options easier. I have a 400x240 panel here I can use for development, but others may want to chime in on desires. Some sample code to output some text on the display would also be nice. Jim

So, is there a thread created for the ecc40 🙂

Dropped a "pwr_fixes" tagged source bundle in github. Would love feedback. Had to make quite a few changes to address power management concerns, while still sipping power when we can. Jim

Thanks. I'll leave it there for a moment. I have power management *almost* working again, but still bugs to fix. Jim

Try the code now in the repo. I disabled sleep for now, but I think I have a way to re-enable it but have it wait to sleep until data is finished sending. I won't commit my new code until someone tests the current commit. Jim

Found it. The problem is in the power management (sleep) code. I didn't write that piece, so I am reaching out to the dev on it. For now, I am planning to turn that off if RS232 is enabled while I debug it, so folks can use RS232 without the issue. I *think* the sleep code needs to ensure there are no bytes to send before it sleeps. But, given that rs232 and sleeping seem at odds, it might make more sense to not sleep when the rs232 channel is open. Jim

Confirmed here. Not sure what the issue is yet, looking into it

Yep, though if that's the goal, it's a better fit for Peter Engel's TIIF (http://pengels.bplaced.net/index.php/tiif). I'd send him a note (he might be on here, but nothing pops up imemdiately) and see if he can add that quickly to the cable. Jim

I'm not sure where I got this from, but I have the specs for the video display, it's attached, though I got it from some TI CC40 web/ftp site. I can't find the location now. That said, it's possible the actual Video Peripheral differs from the spec. Thus, it'd be good to reverse engineer the protocol to see how it matches the spec. The spec protocol looks "VT-ish", but I'm not a VT code expert, so I have no idea if the codes are similar/same I didn't mean to imply char redefinition. I just noted that the spec I received does not have all the char defs in it, but it might be in another doc, or maybe the ones that are in the spec imply they used the normal 99/4a char defs, etc. Display Interface Functional Specification.txt

If folks can create a thread and do some of the legwork on design, I'll commit to add the code to the HEXTIr codebase (and then just compile it for just that peripheral and you can call it the ecc40). Things needed: I think I have the manual for the display... Yep: DISPLAY INTERFACE FUNCTIONAL SPECIFICATION. Done Someone to create the thread and start the discussion... Need a reasonable LCD panel that works with an arduino, at least for development. Needs to be at least 80*7 = 560 x 9*24 = 216, as the specified chars in the doc are 8x6 and you need a spacer pixel. I see some Arduino Mega 800x480 panels that are not that bad, and that's fine, but I wonder if an Arduino UNO panel is available. So, someone needs to research that and I'll buy one/three Get the char set defined. The spec doesn't seem to have the entire char set. I need the set in a C-readable set of array statements. Someone (s) to help wire up a few prototypes. Shuld be minimal, as it's just the resistors/caps/2x4 HEXBUS connector on an Arduino breadboard. A few folks to take those protos and test the nightlies. There's a *LOT* of ESC commands in the spec, and getting them all working will take some QA work. You find 'em, I will fix 'em Things wanted: a couple extra devs to help Folks to nag/encourage me to get this done. I'll probably modify the project to compile for the Mega Arduino, as that way, you can enable all the peripherals at once. But, first things first.

I don't think you can connect a serial interface to the Type B connector to get serial. The Arduino presents as a USB serial device, I believe, to a PC, but it requires the PC to be host to do that. Any USb->serial cable will also expect a host to be involved, so the Arduino would not support those adapters. Jim

I don't mean to call your expertise into question. Electrically, it's not too difficult to interface the 1541 (IEC bus is 3 lines, 5V open collector). I don't know much about DSRs, but if the DSR functionality is flexible enough, you could write the 9900 code to convert raw sector requests into sector request commands for the 1541. So, that would remove the need for an intermediate microcontroller. Still, the resulting disks would be 180kB GCR encoded TI format disks. And, the DSR would potentially be different enough from the normal drive DSR that some apps would not work right. There'd be bragging rights, but it would be FAR slower than the normal PEB drive. Due to lack of communication between the VIC-20 design team and the MOS Technology 6522 VIA production team, a bug inside the hardware shift register in the 6522 was not communicated into too far into the VIC-20 design cycle. A decision was made to fix the issue in software, so the 250kbs hardware transfer speed (25kB/second) was handled in software, where each bit took 40uS to transmit, limiting the VIC-20 to a top speed of 2.5kB/second. The companion drive was called the 1540. When the C64 was introduced, the cycle stealing aspect of the VIC-II display IC required slowing the drive down further, meaning reads from the drive were reduced to 120nS per bit (~900B/second). Though the C64 had a new VIA replacement called the CIA that removed the shift register bug, Commodore decided not to redo the VIC-20 drive and continue on with the software transfer routines. Since the 1540 transfer routines were too fast for the C64, the DOS ROM was modified to increase the delay per bit to 120nS and the drive was remarketed as the 1541. I don't know the speed of the PEB TI disk drive, but I imagine it's far faster than 900B/s. Yes, you can increase the speed of the 1541 drive to ~15kB/s using replacement DOS routines like JiffyDOS, but those require very precise computer timing to utilize (6-8uS for 2 bits). Jim

Ah, OK. Yeah the MFM controller cannot read GCR. 🙂 Sector access on the 1541 is pretty easy using DOS. Just open a buffer, and then perform a U1 command to dump the required sector to the buffer, and then read it in. Write is done similar. write to a buffer, and then ask the DOS to write that buffer to a sector on the disk via U2. But, yes, the arduino solution could just do a high level DIR, open, load, save, etc. Since the TI app would be custom anyway, nothing is gained by doing sector access However, if you want to use the 1541 as a normal TI drive in regular apps, without the custom TI app (i.e. copying a file from 1 TI drive to the 1541 using a TI copying app), sector access would be far easier, since those apps (and the TI KERNEL) expects a dumb drive on the other end. Jim

Given your goal, I'd skip the 1541. It's a poor choice. As @OLD CS1 notes, KryoFlux is the better option. But, if you can get a 360 kB 5.25" drive (Teac drives are the best, IMHO) or temporarily liberate your PEB drive from the PEB and connect to a PC that has a floppy disk controller, there are apps to allow you to read/write disk images on DOS/Windows: IMGDISK might also work, but the thread above seems a better choice (and Kryoflux better yet, though it still requires a 360kB drive). Connecting a 1541 drive to the TI is probably best done via an arduino that connects to the TI via RS232, an DIN6 attached to the Arduino (for the 1541), custom Arduino firmware to talk the special IEC protocol that the 1541 uses, and a special app on the TI that worked with the firmware to read/write sectors and such from the drive. In other words, lots of work and by far the least useful option. A true compatible solution would be a side cart or PEB slot that has a DSR, a CPLD, a microcontroller, the DIN6 port. Then, you would have to decide on two options: 1) treat the 1541 like a raw sector device. The cart/slot would map raw sector access requests and writes to direct sector access requests on the 1541 using the U1/U2 commands. Pros (as it were): very little mapping. Cons (besides the HW work): nothing else really can read/write the disk, as it'd be a TI format on CBM disk. 2) a lot of code to map the direct sector access the TI needs into the abstracted file-based format the 1541 uses. My brain hurts just thinking about how to do that mapping. Pros: CBM machines could read/write the files (not sure how useful that it, but...) Cons: even more code to debug, mapping will have issues, since the two technologies were much different. Jim

1571 reads both GCR and MFM disks. Jim

Yep. Configure a terminal program on your PC, and use a null modem cable from the arduino to the PC to watch what comes to the PC (as if it was the printer). Jim

It's possible there is a bug in the code. Can you connect the serial to your computer and get a dump of what is going to the printer? Jim

I tried it as I was testing it. But, you should make sure Device #20 is enabled in the build you put on the Arduino. Some builds have it disabled to save space or to enable other peripherals. Jim