On Tue, 9 Nov 1999, Roger Merchberger wrote: My recollection was that there were several different vartieties. Each one will have slightly different issues. To add 3.5" HD floppies, you will need to provide a different clock, way to change it back and forth, and support for one more signal to the drive. Why do you want to run more than one FDC? If it is to run 4 instead of 2 drives, you can do that with minor hardware and software hacks to a controller. -- Grumpy Ol' Fred cisin(a)xenosoft.com

Roger Merchberger <zmerch(a)30below.com> wrote: Even if you hack the FD controller's clock and data separator, it's possible that the OS/9 floppy driver may not be able to handle the data rate of a 1440K floppy, which is 500 Kbps vs. the 250 Kbps of the drives it was intended for. That's a byte every 16 microseconds, which is tricky with no DMA or FIFO, since you have to poll for the FDC to be ready for each byte. I was disappointed to find that the optional floppy controller board for the AIM-65 can support 8 inch double density operation (which has the same data rate as the 1440K floppy) only with the addition of another board with a DMA controller. Which, of course, I don't have. I'm not sure that Rockwell even made it.

Dwight Elvey <elvey(a)hal.com> wrote: Ignoring errors gets you into trouble really quickly. I've been down that path. I designed an 1793-based FDC card for a 1 MHz 6502-based system. To get 8-inch double density working, I had to have the hardware provide a second decode for the FDC data register that when accessed would halt the processor until the FDC asserted either DRQ or IRQ, and write an interrupt handler that would recognize that the return address was in the transfer loop and replace it with the address of the error handler. The 6809 tends to take at least as many cycles for simple instructions as the 6502, and sometimes more. In an inner transfer loop of a device driver, the 6809 will win if you need to do unalinged transfers because it can do a 16-bit increment. But I'm not convinced that it's good enough. IIRC, on the Color Computer you can turn off the video and run the processor at double speed. That should probably be sufficient, but somewhat ugly unless you didn't want to use the console. Don't imagine that you can just write a loop (or inline code) to transfer a byte every 16 us. You *must* poll the DRQ bit, because the motor speed control is nowhere near good enough to maintain a constant transfer rate. And even if it did, there's no guarantee that the machine that wrote the disk wasn't a little fast or a little slow. Cheers, Eric

Dwight Elvey <elvey(a)hal.com> wrote: I'm familiar with them, and at 1 MHz the fastest instructions take 2 us. That doesn't let you do very much when you need to transfer a byte every 16 us. IIRC just an iteration of the loop to poll DRQ takes 7 or 8 us if you don't use some fancy tricks.

"Sean 'Captain Napalm' Conner" &lt;spc(a)armigeron.com&gt; posted some analysis of I/O transfer loops on a Color Computer (6809): Or perhaps: POLL: BITB <$STATPORT ; 4 Bcc POLL ; 3 For a poll loop of 7 cycles, assuming that B is preloaded with the appropriate mask. Still no where close to good enough. The poll loop has to go. Or you can partially unroll it and use D: SYNC LDA <$DATAPORT POLL: SYNC ; 2+ LDB <$DATAPORT ; 4 STD ,X++ ; 8 SYNC ; 2+ LDA <$DATAPORT ; 4 DECB ; 2 BNE POLL ; 3 SYNC LDB <$DATAPORT STD ,X+ which gets you down to minimum times of 14 and 11 cycles on alternate bytes. B needs to be preloaded with (sector_size/2)-1. Unfortunately 14 cycles is too close to the limit. For a write operation, you might be able to do slightly better by using "PULU A,B" in place of "LDD ,X++", saving one cycle. Might be good enough. It would be nice to have more margin for speed variation, and I don't think that the Coco can generate an NMI on completion, although in this case an IRQ should do. Of course, the hardware also would have to be designed to release the wait when the interrupt occurs. Partially unrolling this one but NOT using the completion interrupt yields: LDA <$DATAPORT POLL: LDB <$DATAPORT ; 4 STD ,X++ ; 8 LDA <$DATAPORT ; 4 DECB ; 2 BNE POLL ; 3 SYNC LDB <$DATAPORT STD ,X+ For a minimum of 12 and 9 cycles on alternate bytes. I think this one allows sufficient margin that it should work even if the disk is running 15% fast. Based on what Tony said, it sounds like the Coco's FDC hardware can probably support it. Like I said several posts back, transferring a byte every 16 microseconds on a sub 1 MHz processor is tricky.

"Sean 'Captain Napalm' Conner" &lt;spc(a)armigeron.com&gt; wrote: Fine. Just use Y instead. It does add two cycles, but since it's to the path that was three cycles faster, it doesn't really matter: LDA <$DATAPORT POLL: LDB <$DATAPORT ; 4 STD ,X++ ; 8 LDA <$DATAPORT ; 4 LEAY -1,Y ; 4 BNE POLL ; 3 LDB <$DATAPORT STD ,X+ So it's now a minimum of 12 and 11 cycles on alternate bytes. Or, if you insist on using the completion interrupt to abort the loop: LDA <$DATAPORT POLL: LDB <$DATAPORT ; 4 STD ,X++ ; 8 LDA <$DATAPORT ; 4 BRA POLL ; 3 Which has a minimum of 12 and 7 cycles. I'm not sure whether the completion interrupt will happen before the last STD; if it does, the interrupt handler will have to copy the final two bytes from the interrupt stack frame (for IRQ or NMI) or it's own save (for FIRQ). Either way, the worst case is 12 cycles, which gives nearly twice the speed tolerance you'd get at 13 cycles (15% vs. 8%). Cheers, Eric

A non-text attachment was scrubbed... Name: not available Type: text Size: 2470 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/19991110/f32321bf/at…

"Sean 'Captain Napalm' Conner" &lt;spc(a)armigeron.com&gt; wrote: Hi Another factor, the sectors for DOS formatted disk are 512 bytes long. Any loop that only does 256 won't make it. It would need to be formatted with more wasteful 256 byte sectors. This has been a good line of thought ;) One of the other things I remember about these controllers is that at 32us, you need to read the data byte within 27us of DRQ. I would think that this would hold for 13.5us for a 16us transfer. It truely doesn't look like there is a way to do it with anything but DMA. Here is another idea that I fling like a monkey at the zoo. Use a small PIC chip to read the 1.44 disk. Have a small disk cache RAM to hold a buffer ( Not a lot of hardware, so far ). Connect the unit to the CoCo, how ever one would like. Even emulating the original controller so no software needs to be modified, just the effective size of the physical disk ( or map as multiple disk ). Dwight

A non-text attachment was scrubbed... Name: not available Type: text Size: 2241 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/19991111/8bb34c48/at…

ard(a)p850ug1.demon.co.uk (Tony Duell) wrote: Hi Tony If this is true, it looks like it is possible to work wonders with this chip ;) The reason for doing DOS compatable disk is that it makes transfers of info a little easier. Dwight

Rumor has it that Tony Duell may have mentioned these words: The only time you'd see any type of a speed drop from crossing a 256-byte boundary w/the 6809 is if you were using Direct Page addressing and had set the DP register... once you got ready to cross a boundary, you'd have to re-load the DP reg. to continue using the DP addressing. X & Y (& U & S) are all 16-bit index regs (yes, U & S are stack pointers, but they can also be used as index regs) so the DP reg doesn't come into play here. 512 byte MS-DOS sectors shouldn't be too hard to implement in software... if, of course, you had the nitty-gritties to programming the FDC (which the disk Basic unravelled would provide) and MS-DOS's track format layout... (anybody got that handy?) Thanks, and this *has* been fun reading... ;-) I've learned a lot! Roger "Merch" Merchberger -- Roger "Merch" Merchberger --- sysadmin, Iceberg Computers Recycling is good, right??? Ok, so I'll recycle an old .sig. If at first you don't succeed, nuclear warhead disarmament should *not* be your first career choice.

Roger Merchberger &lt;zmerch(a)30below.com&gt; wrote: Hi I have code and stuff I did for 360K DOS disk. It would need a little modifications for the larger FAT used on the 1.44M's but the basics are there. I didn't do subdirectories but they could be added with a minimum of effort. The code is all done in Forth and even then, a strange Forth called CMForth that was for the NC4000 chip. Still the flow is what one needs. It is on my web page at: http://web.hal.com/users/elvey/ scroll down and select: Forth and DSP related files disk.txt DOS disk read write code disk.art Story goes with above floppy.txt Floppy interface ( 765 type, not 1793 ) floppy.art Story goes with above I expect to be doing modifications to the code to read/write to DOS disk in the near future because I want to read/write 1.44M disk in DOS file structures. I am already reading and writing sectors on this disk, just not files yet. Let me know if you find it useful or if you have questions. Dwight

Well, do you still belive Overclocking etc. is still modern stuff talk ? See what you can do with your good old system: http://totl.net/Eunuch/index.html (Start the browser, it's worth, and I can't tell anything :) Gruss H. Back from Helsinki - no Finish computers :( But just today I found two partly plundered MX 300 and a real old MX 500 running for a safe heaven in my storage :) -- Der Kopf ist auch nur ein Auswuchs wie der kleine Zeh. H.Achternbusch

A serious version of this experiment could be executed with a freezeblock on the processor. Some years back they sold cooling fans that included a peltier-element (a diode running a DC current that cools on one side and heats up on the other). The exess heat needs to be fanned away. This way you should be able to effectively overclock a 486DX100 in a practical manner. Sipke de Wal Hans Franke wrote:

I've played with this a little... The first one I did was a water-cooled, dual-peltier "sandwich" cooler. I use a refrigerator compressor to chill the coolant to ~5C and get the cpu slug down to around -40C. I can run my Celeron 366 at a stable 710mhz with that one. The second one I did (well, implemented anyway) is cooled with compressed gas. The coil is fed with a 2000psi dry-air tank and is attached directly to my hot plate. I also get the slug down to between -50C and -40C with this one. I've had the 366 running above 800mhz with it, but the tank runs out before I can do any hard-core tests for stability. The nice thing is that the vented gas can be blown into the case or across heatsink fins to further cool the ambient temperature. Someday I'll invest in a larger tank (arc welder type or something) and see what I can do with it... Fun, fun, fun... On Tue, 16 Nov 1999, Arfon Gryffydd wrote:

Hello all, I have the opportunity to save an IBM 4381 with lots of disks and tapes; it is currently running VM ESA 2.1 and also has two 8232 Ethernet units. With a friend we would like to acquire it and put it on Internet with free accounts to requesters. As you probably know this machine is quite big so I started lobbying my University for space, that would also get power supply and 34Mbit internet connection ;-). The size it prohibitively big for a a single hobbyist but also in the campus floor space it is not free; I must come up with a minimum space requirement for a working system. I don't have any in field experience with IBM mainframe internals and have considered this configuration - CPU one processor - 3420 tape - 8232 Ethernet controller - 3990 control Unit - 1 disk string (3 disks or less but need work on the cabinet to separate the disk subsystems) My questions are: - not planning to use SNA or 3270, at least initially, do we need to set up the 3745 FEP? - is the above configuration reasonable for a minimum system? - tightly packing all the devices to fit in a 15 square meter room will cause heating or other problems? - how may would be interested in accessing the machine? - anybody willing to offer knowledge? IBM was not very helpfully to put it kindly. If you are interested in some way please email me at save4381(a)softstar.it. I have set up this specific account in order to collect, hopefully, lots of emails telling to save the machine. I will pass them to the person responsible for the floor space trying to convince him that we MUST do it. Cheers e. ======================================================================== Enrico Badella email: enrico.badella(a)softstar.it Soft*Star srl eb(a)vax.cnuce.cnr.it InterNetworking Specialists tel: +39-011-746092 Via Camburzano 9 fax: +39-011-746487 10143 Torino, Italy Wanted, for hobbyist use, any type of PDP and microVAX hardware,software, manuals,schematics,etc. and DEC-10 docs or manuals ==========================================================================

"Fred Cisin (XenoSoft)" &lt;cisin(a)xenosoft.com&gt; wrote: Hi Sorry about that, it isn't on a Coco. I'm doing it with a 80C186EB processor and a iSBX board that had a 2793 floppy controller chip. It was a surplus board I picked up at a local surplus place called HSC. I looked at adding subdirectories to my code but, at the time, I couldn't justify it. It really didn't seem all that hard although it did look like a hack job by the fellow that wrote DOS. The code was written with the only purpose of transfering ASCII text from my BLOCK files to a DOS disk. It had no frills. I don't recall all the ins and outs of it but it looked straight forward enough. I think I wrote the DOS code in '91 so I'm not to up to date on exactly how it worked. Dwight

Rumor has it that Eric Smith may have mentioned these words: Erm... I looked up the 6502 instruction set, and while I don't think it's much slower, I don't think (overall) it's much quicker, either. I'll have to double-check my 6809 references, tho. Cycle times seem to be a bit rusty in the noggin... I've not coded in 6502 so I don't know how efficient it is, but with the auto-increment index/stack pointers in the 6809 (and having 4 of them), it makes for some very tight, fast loops. I've never turned off the video on a CoCo, and I'm not really sure you can. The main (read: only) crystal that controls all the timing in a CoCo is a stock colorburst crystal fed straight to the video & into a divider for the rest of the system timing. When you use the double-speed poke, you're changing the divider, so you're not touching the video. However, anything else off the main CoCo bus (including anything plugged into the cartridge port, the serial ports (big-banged :-( ), the cassette port, will get a serious case of heartburn unless you know how to account for it. (and yes, it was *sweet* to save/load proggies from tape at ~3000 baud... I could load a 32K datafile from tape faster than my buddy could with his Commie 64 One good side effect of this is enough hackers tinkered with the double-speed poke timings to fix or patch most any problem you could think of... When the CoCo3 came along which could run at double-speed naturally, when Tandy was so thoughtful to not give any RS-DOS control to the speed, everything was already figured out to get around Tandy's shortcomings. Right... I'm not sure if the disk hardware can even handle the datarate very well (or at all) so all the programming in the world may not be enough to do the task if the hardware falls on it's face. Just didn't know if it'd been done before, and if so, how? Thanks, Roger "Merch" Merchberger -- Roger "Merch" Merchberger --- sysadmin, Iceberg Computers Recycling is good, right??? Ok, so I'll recycle an old .sig. If at first you don't succeed, nuclear warhead disarmament should *not* be your first career choice.

A non-text attachment was scrubbed... Name: not available Type: text Size: 1257 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/19991110/0bb47150/at…