On 7/11/10 6:39 PM, Chris M wrote: Are you sure that was in a CC column? I've read most everything he's published (in BYTE and otherwise) and I don't recall any 68K stuff at all. -Dave -- Dave McGuire Port Charlotte, FL

On Mon, Jul 12, 2010 at 3:39 PM, Bernd Kopriva <bernd at kopriva.de> wrote: Hmm... I think I have those issues in a closet. I'll have to go dig them out. The M68K family is one of my favorites (in no small part due to making a living with it between 1984 and 1994). -ethan

Hi, sorry, my fault: i have just looked up the first reference in Google, instead of rechecking ... ... it should be described in Byte, 7+8, 1986 Ciao Bernd Richard Cini wrote:

Here's an old InfoWorld article that describes it generally: http://books.google.com/books?id=xzAEAAAAMBAJ&lpg=RA1-PA36&ots=34A6…

--- On Mon, 7/12/10, Dave McGuire <mcguire at neurotica.com> wrote: It must have been a l'il smoker. Not easy finding a 68020 though. I think I have a Mac II mobo that's been snapped in half LOL. And it uses a hideous MMU. Doubt that board used anything close.

is that a fact? Please tell me where --- On Tue, 7/13/10, Dave McGuire <mcguire at neurotica.com> wrote:

Chris M wrote: The MMU bit reminded about DACK GROUNDED. I think that was the news letter I saw on the web. Guess what ! All about hooking a 68000 to a apple II for numeric processing. The news letter may be easier to find than a 68020. Ben.

On Tue, Jul 13, 2010 at 3:30 AM, Ben <bfranchuk at jetnet.ab.ca> wrote: Close - DTACK Grounded. DTACK is DaTa ACknowledge, a signal pin that allows for async memory operations... different memory mapped I/O chips or RAM or ROM, etc., can each have different access times, and when their subsystem "knows" that data contents are valid, that subsystem grounds DTACK to tell the processor to continue with the memory cycle (this is in contrast to 1970s 8-bit microprocessors which had fixed-length memory cycles, so you had to have memory and I/O pretty much all the same speed or resort to stall cycles. The trick about grounding DTACK is that when the right phase of a machine cycle comes up, it sees DTACK (/DTACK, really) asserted and keeps on going - as long as your memory and I/O are fast enough, the machine runs at full speed with a non-complex memory control circuit (ISTR the COMBOARD design (c. 1982) uses two bi-polar PALs and maybe one or two TTL parts as well to generate /DTACK at the "right" time, earlier for DRAM, later for EPROM, etc). The author of DTACK Grounded was rather fanatical about the issue (you don't have to read very much to pick up his opinions). If you mean paper copies vs a real chip, maybe not, but for PDFs, the second google hit reveals all... http://www.easy68k.com/paulrsm/dg/dg.htm In my own pile of parts, I have tubes of real Synertek and Motorola-sourced 68000L8 chips, tubes of 68000P8s, and a smattering of oddballs like 68000L12s, 68000Z8s, and maybe a 68000FN or two, but no loose 68020s. OTOH, I do have two ancient Mac 68020 boards that I bought long, long ago (back when one might care to stuff an accelerator into a machine vs buying a faster machine) but never got working. ISTR they are stuffed with MC68020RC16s or something close. I never did much with the '020 in the Amiga world; I jumped right from the straight 68000 (with the occasional 68010 "upgrade") to the 68030 (A1000 -> A3000) At one point, a 68000 motherboard with ISA slots would have fascinated me, but then I started making GG2 Bus+ cards, so any Amiga I run into that has slots (A2000, A3000, A4000...) can have ISA cards. Ultimately, I did very little with ISA parallel ports, a bit with ISA serial cards, enhanced an IDE driver for 1995-era drives, and did a lot with network interfaces. I always wanted to fiddle with unusual cards, but the lack of DMA on the GG2 Bus+ curtailed some options. Something that would still fascinate me is something I saw once - a 68000 CPU (not peripheral card - I have those) for Qbus. More so now than 20 years ago it'd be a curiosity, but that's the sort of machine I'd want to try to bring up from bare metal (but it'd be better with an on-board SCSI controller since real Qbus SCSI controllers are desired by many, including myself, for MicroVAXen). -ethan

I learnt it as 'Data Trander ACKnowledge'. A similar signal to SSYN on the Unibus ;-) -tony

From: "Ethan Dicks" <ethan.dicks at gmail.com> Sent: Tuesday, July 13, 2010 3:56 PM To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Subject: Re: 68K ISA project Cool !! Never heard of DTACK Grounded before, but I quickly read the first issue. Seems fun to read the others ... Probably known in this group, I am a fan of Motorola, not Intel. I learned assembler as first language on an M6800, build my own 6800, 6802, 6809 and finally designed and built a 68000 (which I upgraded later to 68010). In the end I am using a VME board with a 68020 at 30 MHz and RAM at 0 (!) "wait states" in my StarShip. Anyway ... More than 2 years ago, I started rewriting the 6809-based pdp8/e code to 68000. I "envisioned" a pdp8/e on a 68000 board with 8 fields RAM, two serial lines and simulated RX01 (using 3.5" floppy disk drives). I have actually translated the 6809 code to 68000 (making optimal use of all registers of course), but never tested it. I am sure it has bugs :-) I never returned to it due to the FPGA rush and the thought that the 68k code would be slower than a real pdp8/e. I am sure I have a 12 MHz 68k chip, and for some reason I also think to have a 16 MHz version, but I doubt Motorola ever made a 68k at 16 MHz ... Motoral chips have quite some margin in overclocking (I read somewhere). Would there be interest to run a (slow) pdp8/e on a 68k? I coded ASCII "art" for the lights display on a VT220 using ESC sequences. - Henk, PA8PDP

Ethan Dicks wrote: if you want a quick 'n simple way to get into 68K programming. You can always hack a cheap 68K sound board from the Bally Spy Hunter Arcade game -- there might be other compatible games I don't recall at the moment. This is small board with enough Rom/Ram to experiment 'n hack extra hardware to it, plus you can make your own sounds :) Here's a pic http://tinyurl.com/2elga5u Then there's the bigger arcade boards with 68K cpu and plenty of graphics hardware--'n Roms-- on there from Atari, such as the Indiana Jones, Marble Madness, Food Fight, etc --some even have the 68010. =Dan http://www.vintagecomputer.net/ragooman/

And often-forgotten range of 68K machines are the older HP9000s, in particular the HP9000/200 and 9000/300 families. Personally I'd go for a 9000/200 seires machine, although it's only a 68000 (or a 68010 if you are lucky and get a 9817 or a 9826U/9836U), there are many fewer custom parts than in later machines, so repairing them is a lot easier. The 9000/200 machines that I've worked on are very solid (and you'd expect from HP), you can run either HP technical BASIC (which does allow you to run short machine code routines), or Pascal (which is based on UCSD Pascal, and IIRC includes an assembler) -tony

Tony Duell wrote: I thought those ran Rocky Mountain BASIC, which was not the same thing as Technical BASIC. However, I'm no expert on the 9000 series, so perhaps I'm wrong. Eric

On 7/15/10 5:50 AM, Rik Bos wrote: Technical BASIC came out of Corvallis, eventually moving to Fort Collins. There are documents on it for the Integral and 9000 series on bitsavers. The 2000 TSB was a VERY different thing, predating both of them. I just found a product announcement from Computer Design for the 2000A system There are several other BASICs for the 2100 series as well, user written and HP written.

OK, right, thanks... It's one of the nicest BASICs I know (Acorn's BBC BASIC and Microware's BASIC09 are also nice :-)), in that it is very well structured.. Have you realised how to do PEEK, POKE and CALL yet? It's not obvious, but it is in the manuals... -tony

You are probably right. I am (as you know) a hardware person. I understand most of the hardware of the 9000/200 series, I know rather less about the software. And the distribution disks (HP originals) i've just looekd at simply say 'HP BASIC' on them. Can you enlighten me as to what 'Techncial BASIC' and 'Rocky Mountain BASIC' really are? -tony

OK... Although IMHO HP9830 BASIC is farily clsoe to HP85 BASIC and wildly different from the RMB I run on the HP9000... But I guess that's how things evolve. ^^^^ 9915? The rackmount 85. Now that I can well understand. While I love the Integral, I do wonder why it was made so different to the 9000/200 machines. I wish it took the same I/O cards, for a start... -tony

I'm almost certain it did. Of course _I_ prefer the 9830 to any 80-series machine... I really must get round to making a keyboard for mine sometime. Finding an original is next-to-imposible, of course. While I don't doubt that, I think it's clear to anyone who looks at the machines that the 9826 was a replacement for the 85. Just look at them storage to the right of it, etc. YEs, they're very different inside... Did the disk/tape drive diagnostic software ever exist for the Integral? (Things like the CS/80 external exerciser). It was available for the HP85, and the 9000/200s, etc. But having it on a portable machine would be really handy (both for HP field servoids back in the day, and for me now). But Iv'e never heard of it. -tony

On 7/14/10, Henk Gooijen <henk.gooijen at hotmail.com> wrote: I think so. It's more impressive covered in logic prove leads. I still have a Northwest Systems analyer (that taps all the pins via a pod and fat ribbon cables) which does logic and code tracing (buffering the past 4096 bus accesses and driven by a dedicated IBM 5150 PC). I haven't fired that up in years, so I have no idea if it would work without maintenance, but all the gear is stacked in a VAX-11/725 chassis that was stripped at work (at the time, it was cheaper to buy entire 11/725s than individual replacement 11/730 parts) with the pod cables coming out the RC25 hole. ISTR the reset vector is low - there's a fiddly circuit in the Amiga for that, and we had our own "BOOT BIT" that got hammered to migrate the ROM from low to high. I think the "modern" technique is to mirror ROM at $0 and $FFnnnnnn and have a circuit that monitors A23 - as soon ass A23 goes high, clobber the ROM mirror at $0 and open it up to RAM. Right, plus you can have runtime-resettable TRAP and INT vectors. I've interfaced 6821s to 68000s (very simple) and the original Mac has a 6522... Yep. Indeed, though I think even our single-board COMBOARD had address buffers - dunno if that'd still be necessary with 6-8 modern chips on the bus. We had two EPROMs, a DRAM chip, some internal logic for Unibus or Qbus DMA, and 2-3 I/O peripherals (Z8530, MC6821, etc). I'd prepare for the possibility that you'd need to have a couple of '245s there, but for a prototype, you could jumper across the '245 pins and see how the address lines hold up. Yes. Trivially (2-3 address bits and 8 data bits and perhaps 2 gates more than the upper address select logic. Could do that. I can see that. Interesting idea - I think that would be cool. 2x40 displays are much cheaper than 4x40 displays, though. I've picked them up attached to Satellite TV receiver front panels (with LEDs and pushbuttons and software-controllable contrast) from companies like BG Micro for as little as $8. For a bit more, you can get 2x40 VFDs that you could see across the room. The only thing that isn't immediately apparent to me is the switch-to-switch dimension to line up switches with the display bits (if you wanted to do that sort of thing - even simulated lights with just a "boot" switch would be interesting to watch as the machine ran through its paces). Cheers, -ethan

On 7/14/10, Sebastian Brueckner <sb at thebackend.de> wrote: They do, though on the Amiga, for example, $00000000 is routinely filled with $0000 and $00000004 contains a pointer into the master library vector through which all OS resources are accessed, but TRAP and IRQ vectors are definitely at the bottom of the 16MB map. upper bits to trivially slice and dice the memory map into swaths of RAM, ROM, I/O, etc. For the COMBOARD, A23 and A22 are used to divide the entire memory map into 4 zones - RAM at the bottom, then up to 4MB of addresses that map one-to-one over to Unibus or Qbus locations for the host (there's no scatter-gather circuit - you just MOVE buffers into this space and hardware initiates NPR cycles and such), then I/O (with *lots* of mirrors and holes, then ROM (with lots of mirrors). It's an embedded design that was only ever manufactured with 2MB of physical RAM and a 22-bit DMA zone, so the decoding circuit is simple. Workstations and other designs that need to maximize RAM space are typically more complex in terms of address zone decoding. As for "why ROM on top?", I'd say it's because most designers in the 1980s had experience with machines where either RAM or ROM had to be on top or bottom of the memory map because of some architectural requirement (like the 6502, in particular), so they made their 68K designs look familiar. Yes. I think every 68K design I've seen allows for vectors in RAM, but I've seen many techniques to accomplish it. "Know" is a difficult question to resolve. In the case of the Amiga, the ROM code does some very simple checks for things (like ROM signatures, IIRC) then jumps from "low ROM" to "high ROM" before banking out "low ROM" and letting "low RAM" shine through (some Amigas have RAM in the middle, so called $C000000 RAM, so their maps are not contigious, but it's a complex design to be sure). For embedded stuff I've done, I've seen it rigged up so writes to "low ROM" really end up as writes to underlying RAM, so you just copy a routine then push ROM away and fall into RAM, or you jump to some previously established init routine in "high ROM" and use an I/O register to whisk away low ROM. Later designs I've seen keyed off of A23 for a "registerless" solution - but your init code in low ROM had better be doing a jump as the first access above $8000000 or I can see bad things happening. Speed. More code to execute between the initiation of the interrupt and the beginning of the real ISR. Also if you are a _real_ speed freak, as Henk mentioned, you can treat the bottom 64K as a sort-of zero page and run with 16-bit pointers to spend less time setting up registers and such, keeping your code size smaller and your execution times slightly lower if you have RAM at the bottom. If you got your start after age 10, the Wintel monoculture was already well established. Fortunately, there are many, many existing "interesting" machines to study, and plenty of ways to emulate them in hardware or software or both. -ethan

On 15 Jul 2010 at 19:08, Henk Gooijen wrote: If I wanted to explore the 68K instruction set and architecture, I'd probably take the shortcut of using a Coldfire MCU--or even an evaluation board if I could find one reasonably priced. --Chuck

On Thu, Jul 15, 2010 at 5:49 PM, Sebastian Brueckner <sb at thebackend.de>wrote: Back in 1999 I had some of the same ambitions, this ( http://www.chdickman.com/sbc/ ) was the result. Like many things, I never followed through with it. I could interface 68k, 6800 and Intel oriented ICs. I think it has all the signals necessary to add an ISA bus. I did save some edge connectors for the purpose. I keep wanting to get it back out and play with it. A monitor listing and the PLD files are online, but not a schematic. I wanted to put out a schematic, but I got the idea that a kid in college was using it for a class project. Actually with PLD files should be enough to figure out the rest for "someone competent in the field." -chuck

From: "Chris M" <chrism3667 at yahoo.com> Sent: Saturday, July 17, 2010 8:37 PM To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> Subject: Re: 68K (ISA) project Oh, we agree! With "building" I only meant the soldering job. Writing firmware from scratch can be tedious, I know, been there! My first 68k design did not work for over 4 weeks until I soldered a "tool" to see the state of several pins of the 68k at the same time. Back then I only had a 2 channel scope, which were few channels short :-) The mistake was fairly simple (always is when you know it). As coming from 8-bit 6800/6809, I initialized the stackpointer A7 to the highest RAM address. The firmware did work up till the first BSR. Yeah, the stackpointer must be on an even address ... Starting with a real 68k is easy. I agree that FPGA programming has a steep learning curve. I started several times, but never really got through it. Too easily distracted to other "easier" projects, but one day I will get a good start at FPGA stuff. - Henk.

On 7/18/10 5:53 PM, Chris M wrote: That sounds like a wonderful idea. I am definitely interested. -Dave -- Dave McGuire Port Charlotte, FL

On 15 Jul 2010 at 19:32, Henk Gooijen wrote: One of the recent uC eval kits features a small OLED graphics display. I haven't the faintest idea who sourced it, but I was surprised to see it on an eval board. --Chuck

On 15 Jul 2010 at 13:59, Dave McGuire wrote: Yup, but by and large, they're LCD. It was the OLED that surprised me. Shades of the Sony XEL... --Chuck

On 15 Jul 2010 at 14:20, Dave McGuire wrote: Luminary makes an ARM eval board with a tiny 96x16 OLED display-- about the size of a 0.300" DIP. On the other hand, Domaintech offers an Actel FPGA board with a very spiffy OLED display: http://www.domaintec.com/A3P-OLED.html But heck, they're integrating the things into pushbutton switches now: http://www.nkksmartswitch.com/products/oled.asp Cheers, Chcuk

On 07/15/2010 01:36 PM, Dave McGuire wrote: My friends at Wohler are using those OLED switches in a video switcher application, so each input selection button actually shows a thumbnail of the live video. They've demoed it at trade shows but I'm not sure whether they're shipping the product yet.

On Thu, Jul 15, 2010 at 01:29:03PM -0700, Chuck Guzis wrote: And should you feel the weight of too much disposable income, Art Lebedev is happy to sell you the Optimus Maximus keyboard: every key has an OLED display on it. For the bargain price of USD 2400 ... http://www.artlebedev.com/everything/optimus/ droolworthy: oh yes worth the money: you've got to be kidding ... Regards, Alex. -- "Opportunity is missed by most people because it is dressed in overalls and looks like work." -- Thomas A. Edison

On 7/15/10, Chuck Guzis <cclist at sydex.com> wrote: You could be spammed by 113 pr0n sites *simultaneously*! -ethan

Alexander Schreiber wrote: I've never understood the point. The *last* thing I want to look at is my keyboard. Fingers on keyboard, eyes on screen. Eric

On 16 July 2010 02:46, Eric Smith <eric at brouhaha.com> wrote: Perhaps Sir would like the Happy Hacking Keyboard? -- Liam Proven ? Profile & links: http://www.google.com/profiles/lproven Email: lproven at cix.co.uk ? GMail/GoogleTalk/Orkut: lproven at gmail.com Tel: +44 20-8685-0498 ? Cell: +44 7939-087884 ? Fax: + 44 870-9151419 AIM/Yahoo/Skype: liamproven ? MSN: lproven at hotmail.com ? ICQ: 73187508

On 16 Jul 2010 at 3:29, Liam Proven wrote: Keyboard? Who needs a keyboard? http://www.pddnet.com/video-mousless-the-invisible-mouse-071210/ Cheers, Chuck

--- On Thu, 7/15/10, Eric Smith <eric at brouhaha.com> wrote: ? touchscreens have been around forever dude. Now you can throw away yer k/b and fumble around on yer screen altogether. And 2 inches from your nose.