Mooroolbark
I think I did that after a few too many beers the other weekend...
The early 1980s gave the world its first taste of cheap, user-friendly micro-computers and saw the likes of the Sinclair Spectrum, Commodore 64 the Atari 400 and 800 and the TRS-80 find their way into homes around the world. In Australia, a company called Microbee also decided it wanted to give the world a micro-computer based …
I discovered this the other day when someone asked me to check the contents of some old floppies. It's only a month or two since I ditched four or five of the things, thinking that they'd be ten a penny on eBay if I suddenly needed one in the near future... oops!
Still, I dare say a rummage in the various piles of antique hardware lying around will turn up a suitable machine with one already installed.
I have one of those dual 5.25" / 3.5" drives in the basement just in case I want to get content off old floppies some day. Of course finding a controller is now probably difficult - though I wouldn't be surprised if someone has a USB-to-IDE converter out there that would work. I should pick one up just in case.
(I think I have a PC Card IDE adapter, but PC Card slots are getting hard to find too.)
Sure about that? Most floppy drives are not IDE, even if the data connector on 3,5" looks mildly similar (but shorter).
Not at all - sure, that is. I haven't looked at a floppy drive in years, so I was almost certainly misremembering the connector type.
I do have a couple of ancient desktop machines that might conceivable come back to life with sufficient prodding.
Of course the MFM controller logic wasn't terribly complicated, if memory serves. And the 8088 source code for driving it from the original IBM PC BIOS should be in the BIOS listing in the IBM PC Tech Ref. Maybe it's feasible to build a controller with an FPGA, without doing a silly amount of work.
True, MFM interface is not terribly complex. But why bother, when most PC motherboards up to Pentium 4 era have FDD and IDE interfaces on them. Unless there's some fun to be had in building such a thing.
I'm keeping a venerable PIII server around for such necessities- it has an ISA card slot, assortment of PCI slots, COM & LPT ports, floppy drives, IDE, Ultra160 SCSI. Oh, and 12x Plextor SCSI CD-writer is frequently able to read a faded CD that's quite unreadable in newer drives.
For 3,5" floppies, very useful thing to have in a toolbox is a TEAC FD-05PUB USB floppy drive. True classic, most widely supported by BIOSes and operating systems.
Well, those old floppies and CDs are not becoming any younger. I'd suggest that it's about time to salvage all useful files from old media.
Sorry, memory bypass. Or perhaps a severe case of repressed memories. Floppy interface is far from easy to reproduce, it's an unholy mix of analogue and digital.
Should have remembered a student project to do a WD179x clone for a CP/M micro. Resulting board wasn't much smaller than a 5.25" drive itself, required lots of calibration, and could read double-density floppies on a really good day. HD 1.2MB / 1.44MB formats are yet another layer of complexity. Eh, gory days.
IDE, on the other hand, is mostly a software operation, it requires only 3 TTL chips to implement.
There were *lots* of Y2K bugs. The bulk of the real Y2K effort was in making sure that they didn't live to see the 21st century. The"internal clock"-type errors like this were only the cosmetic tip of the iceberg.
It will be interesting to see exactly how many Y2K-type issues there are on this kit...
"There were *lots* of Y2K bugs. The bulk of the real Y2K effort was in making sure that they didn't live to see the 21st century."
Indeed, and it's a testament to the skill of the people involved in correcting them that we were not badly affected by those bugs.
One of the nastiest "y2k" bugs actually hit in 1998 - when unixtime (seconds since 1 Jan 1970) got to a high enough value that signed/unsigned representation mattered.
Half the routers around the world went down (CIsco's NTP implementation was ok, many others were not), including _all_ of china.
If more programmers actually knew how computers worked, and learned how to do what they do in a resource limited environment we might have fewer security issues to deal with.
When you grow up searching for somewhere to squeeze in just a couple of dozen bytes of code you get pretty good at recognizing code which performs no useful purpose, and even to a certain degree, does more than it appears to on the surface.
My first effort, it was replacing the cassette tape code on my old Apple ][ with an inline assembly language print routine. POP the return address, output (through the I/O hooks so DOS could see it) whatever followed the JSR call until a 0x00 was reached, PUSH a new return address, and continue.
With an overlaid Monitor ROM I eventually had a suite of "inline data" calls which made my machine code very difficult to disassemble, (at least until you realized what was going on) but my macro assembler source code, very easy to write and maintain. The fact that it wouldn't work on any other machine but mine unless that machine was modified with a piggyback ROM was a niggling detail.
The second to top photo is Samsung's long awaited answer to the Retina 5k iMac. A Samsung spokesperson opined: "this time, I really think we've nailed it! We totally understand what people want in a computer, like we totally understand what they want in a smart watch. We've been clever enough to mimic the iMac closely but not too closely - I think it'll sell at least as well as our Gear Watches".
The Samsung MicroiBeeMac 64 goes on sale on September 9th for pretty much whatever price Apple wants for theirs.