At 12:33 AM -0600 12/29/08, Jim Brain wrote: I'm glad I own a MMC-Replay cart, especially with the RRNET option, but if the uIEC had been available I might not of purchased it. While you can mount D64 images, you can't run most software from them. I think the situation might be better on PAL C64's. I've found that Individual Computers has a habit of advertising features that don't quite live up to my expectations. I also own a Catweasel card for my Amiga, and even though I bought it nearly 10 years ago, I'm still a bit ticked over it. If something doesn't include device drivers, you shouldn't advertise it as supporting various formats. It basically could read 2 of the floppy types it claimed to support. If you support Mac & Linux this might be of interest to me. My major problem with just things has been the fact that it only ever seems to support Windows, and I don't typically have a Windows machine running. One question, what size SD cards does the uIEC support, and does it support HDSD cards? Right now I'm using the 2GB card from my MMC-Replay and it wants its card back. :-) Zane -- | Zane H. Healy | UNIX Systems Administrator | | healyzh at aracnet.com (primary) | OpenVMS Enthusiast | | MONK::HEALYZH (DECnet) | Classic Computer Collector | +----------------------------------+----------------------------+ | Empire of the Petal Throne and Traveller Role Playing, | | PDP-10 Emulation and Zane's Computer Museum. | | http://www.aracnet.com/~healyzh/ |

On Mon, 29 Dec 2008, Jim Brain wrote: Excellent news! I might buy one of the SDHC cards for the uIEC and give the MMC-Replay back its 2GB card. I have a large enough SID collection on the 2GB card, it is actually a little bit cramped. One of the things the MMC-Replay does do a good job of is playing SID files. Zane

On Mon, 29 Dec 2008, e.stiebler wrote: I suspect that the uIEC is just a little tied to the IEC bus. :-) Personally I was just thinking a couple hours ago how nice it would be if someone would make something like this for the Amiga 500. Zane

On Mon, 29 Dec 2008, Zane H. Healy wrote: Zane, you could just use an IDE-CF bridge. That's what I use in my Amiga 2000 (albeit with a SCSI-IDE bridge in the middle of that). g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind.

A600 have IDE, I have one here (although with a broken keyboard). 1200 usually has troubles with electrolytic capacitors on motherboard, this is an easy fix. If you want to play floppie games on the 500, the easiest way is: - A1200 - Memory expansion (at least 4MB) - CF card or Hard Disk - A program that read image floppies and emulate a floppy. I don't remember the name now, but it is easy to find on the net

Maybe a PC memory heatsink on top of that? :)

Nooo, you did it all wrong! The heatsink must be on vertical!

Now the heat sink can dissipate the heat propperly, remember that hot air is less dense than cold ar, so the cold air will go left-right and the hot ar will be down-up, making a perfect conveccion movement. Why go to MIT when you can subscribe to cctech?! ----- Original Message ----- From: <bfranchuk at jetnet.ab.ca> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Sent: Tuesday, December 30, 2008 5:54 PM Subject: Re: uIEC/SD == AWESOME! -------------------------------------------------------------------------------- No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.1/1868 - Release Date: 29/12/2008 10:48

Tony Duell wrote: Well, uIEC tries to hit the $50-$100 price range, so it's not terribly expensive, but provides enough profit to pay for my tools I needed to buy to create it and add functionality to it. The plans, source, PCB, etc. are all under GPL v2. However, for the ASM lovers and the C haters of the list, I will note that almost the entire firmware is in 'C'. Jim

Actually, I hate C. Dunno why, just never developed a taste for it. I can write C, but I don't like to. Most of my projects are in Perl. If you forced me to use a low(er) level language, I would probably use Forth. -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- Time makes more converts than reason. -- Thomas Payne ----------------------

I call that 'not too expensive' :-). Nobody is saying you have to make a loss :-). It's just that some of the commercial solutions are many thousands of dollars and I simply can't afford that for an add-on to a hobby system. OK. That's open :-) There's a na English proverb 'Never look a gift horse in the mouth' :-). Yes, I do prefer assembly language over C. But if I am being _given_ something I am not going to moan... Actually my main moan on C for microcontrollers is that the compiler is either expensive or I can't sensibly run it, or both. -tony

On Tue, 30 Dec 2008, Alexandre Souza wrote: THAT is worthy of a complaint. The good old days are gone, but do we HAVE TO face that?

Hnag on a second. Last week yopu were all telling me that I could program just about any modern microcontroller using whatever classic computer I liked. Now you're telling me I have to use C (and presumably have some machine that can host the C compiler). Which is it? :-) -tony

Chuck Guzis wrote: That possibly depends on the definition of assembly. To me it's something along the lines of "the lowest-level instructions that can be fed to the CPU" (even if those instructions might be quite involved and do multiple things), so it's hard to imagine a CPU that didn't essentially support assembly. What the user gets to see is another matter; I expect lots of systems have existed where the "bare metal" is essentially hidden from the user. I've never looked into Sun's Java CPUs to see what they do, but I bet the bytecode that they run is pretty low-level rather taking the higher-level constructs familiar to most programming languages. (Interesting question, though - I wonder what a CPU might look like where you could just throw C source code at it, for instance :) cheers Jules

Cameron Kaiser wrote: It's optimized in the sense that it's a stack based architecture. i.e. no registers. You work with it as if it has registers, but your registers are offsets into the stack based on the stack pointer. It's kinda CISC like, opcodes aren't all the same size, but it's also RISC like in other regards. I don't recall if it had an FPU, but it did have a separate chip for an MMU, another one for video, another one for PCMCIA I/O - was a whole family. Far as I know, was only used for the AT&T Eo and very early Be Boxes. Funny thing about it, it was built for Apple's Newton project, but they chose the ARM chip instead. But they went into Eo's instead. Go's Penpoint OS is used in the Eo's - IBM made a touch screen thinkpad that could run either PenWindows or Penpoint. It's interesting to note that while the 486 inside the Thinkpad (I think it's a 730T?) runs at the same clock rate, runs the same OS, but the Eo runs circles around it. :-) So certainly, the Hobbit could kick the crap out of a 486. Sad, it was a neat little CPU. Too bad nothing else used it. There were two Eo's, 440 and 880. The 880 even had SCSI support and a floppy drive port too. There was also a funky cellular module (analog of course) with a full size desk phone handset that it cradled. Both used SRAM PCMCIA cards and a PCMCIA like ROM slot - both had internal hard drive options, but the drives from the 880 don't match those in the 440 - they're all nonstandard. The 880, but not the 440 also has a backlight, but it's not software controlled, there's a hard switch that you can use to make it light up. They use a magnetic digitizer, so you need special pens. The pens from the 730 Thinkpad work with the Eo's and vice versa (I think). The Eo's spoke UUCP over their cellular modem and could thus receive/send email that way. The Newton of course had much better handwriting recognition, so the Eo died (to be in turn killed by Palm), but despite that, Penpoint was an interesting OS that had the look and feel of a paper organizer (tabs, pages, etc. as opposed to desktop GUIs which appropriately use a "desktop" metaphor.) If you recall the "AT&T You will commercials" back in the early 90's - the ones with "Have you ever sent a fax from the beach?" - they showed an Eo without one of the ears. The ears contain a microphone on one side and a speaker on the other.

Actually, the pen OS I was the biggest fan of was Magic Cap. I have a DataRover 840 with an Ethernet card and it's rather fun. It even has a primitive web browser. -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- I shouldn't have to explain this to someone old enough to type. - S. Gardner

Chuck Guzis wrote: ... I remember reading a computer architecture book back in the early/mid 80s, I think it was by Stone. The subject was "advanced" architectures. One section described on attempt to build a timesharing system for running a BASIC-like subset, and everything was hardwired -- parsing was via gate-level state machines, not microcode. The intended audience was college-level computer classes. As I recall, they gave up after getting a simplified version going. The exposed pipe hazards weren't the real issue. The problem was exceptions. In certain states, there was no simple way to restore the pipe, so the interrupt handler had to detect when one of those bad cases existed, then nudge the state along one instruction at a time until it go to a point where it could restore the state fully and really return I never saw it, but I heard the return from interrupt code was a couple thousand lines of tricky assembly.

Jim Battle wrote: ... I forgot to mention I had the author wrong. "Advances in Computer Architecture," by Myers. Mine is the second edition, 1981.

On 31 Dec 2008 at 17:03, Jim Battle wrote: Such efforts seemed to me almost always to come from the university environment. In the commercial setting, languages didn't seem to matter as much (unless they were mandated by goverument contract). I haven't the faintest idea how many different anguages that I've had to learn during my life, but it's been a lot. The nice part is that now I forget them as easily as I learned them. I'd heard that the latency of interrupt servicing could vary wildly, which meant that the most successful i860 applications were those where no interrupts or context switches were required. The MS implmentation of NT must have been a riot to use. Did any copies ever make it out of Redmond? I have the Margulus (sp?) book on the i860. I remember initially being very interested but noticing that I seemed to develop a headache every time I picked the book up to read it. Just found the book on my bookshelf, opened it and now my head hurts. I guess the book still works. Cheers, Chuck

Sridhar Ayengar wrote: ... I tried googling this, but find no references. Do you have any? When was it made? Who was the market?

I presume this was to be part of the T/S home computer line? Like a post-2068 model? -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- Time makes more converts than reason. -- Thomas Payne ----------------------

On 1 Jan 2009 at 12:45, Alexandre Souza wrote: Wow, if that claim is made with a straight face, it has to be an invention of some marketing type. I've coded my share of AVR assembly and certainly wouldn't characterize the uC that way. Perhaps the TI MSP430 uC could be said to be "optimized for C"; it reminds me of the PDP-11 architecture. Cheers, Chuck

On 2 Jan 2009 at 8:29, Jochen Kunz wrote: Perhaps compared to an 8051, and a PIC, but literal constants in program memory have their own addressing problems (LPM uses twice the program space address and is the only access to program memory). Since SP is in I/O space and not register space, it takes extra instructions to perform stack-relative addressing (got to get SP into X, Y, or Z) for stack-local variables, etc. Compare that with the TI MSP430. 16 16-bit registers, PC is R0, SP is R1, Status is R2, R3 is a "constant generator" and the rest are uncommitted. Von Neumann architecture, 7 addressing modes... The 8051 is a little clumsy, but a genius compared to, say, the 8x300 uC. But C can probably be implemented on any binary uC, given enough ugliness and memory. Cheers, Chuck

On 2 Jan 2009 at 3:25, der Mouse wrote: I did say "C can probably be implemented on any binary CPU, given enough memory and ugliness". Probably even an 8x300. I work with both PICs and AVRs (my current project uses an ATMega128), but both instruction sets seem to me to be more than a bit contrived. The AVR less so than the PIC, but still on the "odd" side of the ledger. Why, for instance, on the AVR, am I restricted to 16-bit register pairs X, Y and Z? Why does LPM work only through Z? Why can't I use any register pair to address memory? To be fair, the TI MSP430 is a 16-bit chip, not an 8-bit one. Not that the TI chip doesn't have its drawbacks. It's available in 3.3v only and doesn't match the speed of higher-end PICs and AVRs (top clock speed for the 430 is, ISTR, 16MHz). The unified address space imposes limits on the size of RAM and program flash. But the instruction set's a marvel and the chip is extremely miserly with power. I'm not a 430 evangelist (and suspect that it will never enjoy the popularity of the PIC or AVR, which is a shame). I'll work with any instruction set, but I know what I'd prefer to use. It's curious that the MSP430's instruction set is close to the GI CP1600, where the PIC is descended from the very different 1650. Cheers, Chuck

On Jan 2, 2009, at 2:29 AM, Jochen Kunz wrote: I dunno, I rather like the mcs51 architecture. I use it quite a bit. Far nicer than other Intel designs. -Dave -- Dave McGuire Port Charlotte, FL

On Jan 2, 2009, at 2:22 PM, Jochen Kunz wrote: Many have said good things about AVR...including a few people whose opinions I value, now including you. I plan to check it out someday. For now, my "tiny" projects use PIC, my "small/medium" projects use various 8051 implementations, and my "big" projects use ARM. I will add AVR to that list when I have some time to check it out. -Dave -- Dave McGuire Port Charlotte, FL

Jules Richardson wrote: IBM mainframe architecture resembles this remark. Evidenced by the instructions for unpacking packed-decimal numbers, stripping off leading zeros, putting a dollar-sign in front of the whole thing, and storing the result. All in a single instruction. Peace... Sridhar

... Assuming said classic already has a native C compiler and sufficient memory, I assume. I've yet to see a GCC-anything that will run on an 8 bit micro, for example. -tony

e.stiebler wrote: Has anyone ever tried a CBM IEEE DRIVE on an HP? If the differences are trivial or not too insurmountable and I had someone to help me (I have no HP machines here with HPIB to try), i'm happy to add support. Jim -- Jim Brain, Brain Innovations (X) brain at jbrain.com Dabbling in WWW, Embedded Systems, Old CBM computers, and Good Times! Home: http://www.jbrain.com

e.stiebler wrote: I'm in Iowa. If that works, I'll keep you in mind. I don't need it yet, as I need to get some basic IEEE488 stuff implemented. Jim

Tony Duell wrote: This is not as problematic as it may seem. The uIEC can auto-update the firmware, so I could simply write a special version of the SW for HPIG/GPIB (even different flavors for the various command sets) and the owner can simply place the flavor desired onto a flash drive, turn on the unit, and it will program itself with the correct DOS. I am hopeful someone finds enough value in the possibility to provide a unit for testing. Still, this is very premature, since I still need to get the PET IEEE stuff working. It'll be a bit-bang approach, so save HW costs, but I can wire up some TTL logic if needed. Jim

Tony Duell wrote: 10000 Anything is possible. I'll post to the list if I get that far. I'll check into this (any other links to HPIB interfaces?) Right now, I'm fighting with the fact that I believe the full complement of IEEE-488 signals is 17, and it sure would be nice if I could get it down to 16

I'm coming late to this discussion, and I'm only on CCTech, so I may not have seen everything (not to mention not having had internet over Christmas, and having a lot of messages to skim as a result), but I'd like to get my bit in. Jim Brain wrote: You can probably make do without REN, too. The PET has it tied to ground, i.e. permanently asserted, for a start. Just assume it's asserted and you won't go far wrong! Commodore drives do some strange things with GPIB addressing. Bit 7 isn't supposed to be used, but I think Commodore use it to add a flag to the primary address when opening files. ISTR they may even use bit 6 this way, thus preventing you from having a device at (disk drive)+16. I don't have much HP stuff (although I do have some 80-series boxen), but one drive I'd like to see emulated would be the Tektronix 4907. This was a device for adding 8-inch floppies to your Tek 4050 series. The 4050 series has its own quirks with GPIB. The one that most annoyed me when I was using a Commodore 8050 with my Tek 4052 was its habit of asserting IFC when you least wanted it to. Like immediately before loading a program, thus causing the 8050 to forget all I had laboriously told it about the program I wanted to load... Philip.

Apologies for replying to my own post, but... If I had engaged brain before opening text editor, I would have realised that this is bit 4 that is being misused. Bits 5 and 6 are correctly used to say what sort of address it is - talk, listen, secondary. Philip.

Tony Duell wrote: The unit I am using has 128kB of space, of which I am using 4kB for a bootloader and 51K so far for uIEC DOS. But, a HPIB/GPIB based unit can dispense with things like D64 images and such, so I think there may be plenty of room. There are provisions for 3 switch inputs, which could be used for drive and interface selection. It *might* be possible to load everything into one firmware image, but I think it'd be best to keep the CBM/non-CBM stuff separate. I'm planning on OC outputs. My idea is to make the ATA (IDE) interface do double duty. As I look at the signal table for ATA, I notice a few unused states: /CS0 & /CS1 = IEEE CS A0 selects data or control lines READ selects a read WRITE selects a write I'll probably use the 75160/75161 ($4.00 for SOIC, $2.80 for DIP for the two ICs), though I prefer '245s for the inputs and TPIC6B273s for the outputs. (3.40+.82 = 4.42 for the 4 ICs). A single '138 should decode what I need from the IDE control signals. Jim -- Jim Brain, Brain Innovations (X) brain at jbrain.com Dabbling in WWW, Embedded Systems, Old CBM computers, and Good Times! Home: http://www.jbrain.com

Tony Duell wrote: Not sure. I do have the ability to add an entire latch of switches on the IDE bus (like I am adding the IEEE-488 support.) On the current unit, you send commands to the unit through the command channel to change such things, so maybe that is another option (pick the command set from the front, then issue a command to pick a device type and choose an alternte address). On the latter, the uIEC supports the same idea. It boots as device #10, and you can modify it via software. So, you put it alone on the bus, issue a command to change the number, saves it in EEPROM, and then you plug in the rest of the units. Actually, they are. When I was composing the email, I initially wrote about using latches and transceivers, but then decided (with this crowd) I should do a bit more investigation before I posted. Along the say, I found the 75XXX units, and they weren't that bad in price. But, right after I rewrote the msg and sent it, I realized that I'd still need 2 latches to hold the outputs for the 16 bits of IEEE data, and another latch to save off the TE state (on the 75XXX ICs). As well, I'd be locked into IEEE 488 usage. So, I scrapped my idea, and went back to my original ideas, TPIC6B273s and 74LS245s. It's the same price, and I could support more interfaces. '38s are somewhat iffy, in my mind. MC3446 and the 75XXX line sink 100mA, and the '38 is 48, max. Coupled with the higher parts count (4 '38s, plus 2 '374s = 6 parts as opposed to 2), the price is only marginally better (3.40 versus 2.40). If the solution finds value outside of the vintage community, I could see one on a long GPIB chain, and I'd hate to fail in that case. With 150mA sink, I'll be the last one on the bus to fail. Jim