Reminds me of a video I saw online somewhere, a while ago, where someone bootstrapped an old TRS-80 by typing a simple program that would write the bytes from a serial port into memory. Then he could transfer a better program using the first program. The second program, if I recall correctly, was Kermit. Now he could run Kermit from floppy drive and he could use XModem or whatnot to transfer files over the serial port and save them to floppy disk. Pretty neat. I wish I remember more of it.

===Jac

Those ubiquitous Atari-style joysticks are digital. 5 discreet switches; one for each direction plus "fire."

I had a blast 5 years ago or so, when I got my Apple ][e running by keying in an old version of ADT, and using that to install the new version. I entered it in very sloppily because it didn't work right, but worked just good enough.

I've been thinking about this recently because I suspect a retro-computer purist would only want period appropriate hardware. So using a modern computer or microcontroller as a terminal emulator is sort of cheating.

A keyboard is a solvable problem, but the display and mass storage are harder to be remain pure. Computers of that era tended to use custom display IC's that are long obsolete and hard to find. Cassette tapes and floppies are also obsolete and pretty clunky. So I am using microcontrollers for the display and mass storage access.

I've seen VT-400 and 500 series terminals on eBay for about $100. But that's expensive and space consuming just to prove a point. It also would not solve the issue of mass storage.

Well that was what was troubling me when I was pondering making a machine.

"What does a computer need?" Input, output, storage. Running a terminal didn't bother me, nor running a terminal emulator on my main machine. I mean, yea, it would be neat to have color graphics and what not, but, especially on the slower, older, machines, the impact those display system have on the machine are pretty tremendous. From the large amounts of RAM, to cycle stealing, etc. Graphics weren't cheap.

But them you get to storage. "Oh, well, a floppy disk" But how to do that? Only to find FDC chips aren't really made any more. I don't even know if the Apple used an FDC chip like the Z80's did (knowing Wozniak, he probably just cobbled something together out of spare parts he had in his pocket). Then there was the problem of getting a floppy formatted, and that whole toolchain. Then I realized that at least with the C64 and Atari, they basically used serial devices that happened to be Floppy Drives for their mass storage.

Then you start pondering using Flash memory, and find nice little devices that run I2C that you just send over a file name and start streaming data, and they handle the flash memory, and DOS format, and have the entire file system as a service. Well, now your "floppy drive" has an even more sophisticated microcontroller than the machine you're building. You have $100 in parts and boards and what not to get your 2Mhz computer to talk to a $5 microcontroller that out capabilities your machine by orders of magnitude, delegated as a serial slave for mass storage.

Well THAT made a lot of sense.

So, it just made me rethink the entire process, and I ended up writing a simulator instead.

My current little project in my head is to get a Raspberry Pi and wire it up to an FM chip and turn the thing in to a clock radio and DRR -- Digital Radio Recorder to record off the air radio shows. I can't believe there really isn't a good commercial product that does that. Seems with a little work you can wire up the module, consume the digital audio signal, and dump it to files -- then the Pi can present a web interface suitable for Podcasts.

No doubt it'll be harder than it sounds...

That depends on whether the hobbyist has built a truly retro machine. In my opinion, mere use of the 65xx family doesn't automatically make the unit retro. My POC V2 unit uses up-to-date hardware to go with the 65C816. It's definitely not retro.


I'm sticking for now with a dumb terminal means of controlling my contraption. That will eventually change as I bring something to fruition.

As for mass storage, I went the SCSI route, as SCSI and I are old friends from the mid-1980s when the standard was originally ratified. Parallel SCSI drives continue to be readily available and have been manufactured in capacities as high as 300 GB. There are also SCSI tape drives available, making for a viable means of creating off-line storage.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I'm not a purist. Besides which, I'm shooting for a portable device with my build. It ain't there yet, but it'll get there.

The keyboard was going to be a hacked chatpad, like Ben Heck did for his pocket BASIC computer. I didn't read the ebay page properly, though, so I got a knockoff that I couldn't flash. That's been binned in favour of an RC2014 serial keyboard. Very solvable, as Martin_H observed.

I've been having trouble deciding what I want to go for, display-wise. There are some TFT LCDs that I've been eyeing off, but the datasheets are nasty reading. They often don't use the standard terms(like I2C and SPI), they tend to be huge(200+ pages), and they aren't always clear on where the information is. This makes writing a driver look like an exercise in frustration.
I did try a 20x4 character LCD, but I think it's dead. I might be trying to drive it wrong, though, as the datasheet's terrible(this seems to be the case for all of Xiamen Ocular's datasheets). That said, there does exist a serial 128x64 graphical LCD from Sparkfun that I'll have a closer look at. It may well dovetail very nicely with my existing hardware.

I have some SPI EEPROMs that I plan to use as storage, hopefully via a 65SPI. On the other hand, I may go to an SD card later(They're relatively cheap, so hang the irony), for the sheer storage capacity, but that'll only happen if units of 64KB get cumbersome, or if I decide that I want internal storage.

Slightly OT, but a clever hack along similar lines: some people wanted to automatically install a driver for their USB device on a PC. The solution was that the device would pretend to be a USB keyboard, send certain keystrokes to open up the cmd window, start the Windows 'debug' program, type in the driver, and save it. With the driver installed, the device would unplug itself, and plug back in with a different function.

I do like that hack, Arlet!


Indeed he did - I think it was just six chips. Maybe six logic chips and two ROMs to make a state machine. It was even higher capacity than the standard, because it used GCR coding.
http://www.retro.co.za/ccc/apple2/disks ... ntrollers/

I'm not a purist either. Back in the day I was always looking for faster, larger, more efficient etc. for the computers I was working with. So if I still do, I don't see any problems with that. SCSI in the eighties was a great upgrade to what came before, where you couldn't even move disk drives between controllers. Current loop to RS-232, then Ethernet, first X.25, then Internet. Multi-windowed RS232 terminals, all of this made it easier to do what I wanted - which was to work with the computer. I did my time with an Apple with four floppy disks, which, with the 'swapping' feature of the UCSD P-system, gave me barely enough memory to write my program. Around 1990 I moved to Unix workstations, and used them for what they were worth and moved data and files forth and back between the original systems and the Unix boxes. I remember spending a week on the old system, on a customer site, porting a big Fortran program from VAX Fortran to my mini's Fortran. Just when I finished, the author walked over with a new version.. argh.. well, no problem, I copied the source for all the three version (old, ported, new) to a Sun machine at home, over the network, and used diff and patch (remotely) to auto-port the latest version. Copied it back over the network. A 30 minutes job, saved me another week.

In short, I have always used the tools available, and that's what I still do. The old computers were extremely interesting to work with, and still are, but the clunky interaction was never part of the charm. So I have no wish for 'native' editing and compiling, for example.

The mini I have in the basement has 2MB of dynamic RAM, on a big memory board. The latest of that kind I worked with, in the early nineties, had 6MB on the CPU board (slightly more modern than what I have now). I wouldn't hesitate for a second if I could somehow install 24MB of modern static RAM with a small board hooked up to the system. And I will try to replace the SCSI disk with an SD2SCSI board - I like SCSI, but this disk is from 1988 and also noisy, and modern SCSI drives are tricky to get working on this system. There's enough noise as it is, so I don't need the SCSI to hear that the machine is on. So, it'll be SD. And I'll figure out something from the floppy too. I worked enough with these systems in the past to realise the unreliability of hardware with moving parts.

There's one exception w.r.t. old I/O though.. those old teletypes, when they finished hammering out whatever your program did, or maybe just finished the bootup process, the print head would move to the left and down a line, and with sudden silence, sit there with a kind of expectancy. Maybe there was a 'Ready' prompt. Waiting for you. Unlike a VDU terminal cursor. The teletype was alive, in a way. Can't replace that with anything modern. But I still don't want to write and edit my program on one.

This. I struggle with the sliding scale of purity. Using a µC more capable than the 6502 is a step too far for me yet I dislike the large PCBs that discrete logic entails and period video controllers were designed when SRAM was expensive, so video modes are many and convoluted. I've settled on FPGAs as a happy medium. If I look the other way then I can pretend that it's a large PLA yet I can have an SPI master core and fine-grained address decoding in a single package. Then I wonder if I should just put the 6502 core in the FPGA and use SMT SRAM but DIP parts just look too cool. If there was a breakout board that put an iCE40 in a DIP64 form factor then I'd be all over it like a rash.

Two ideas for you: dipsy, and tgl6502. Also, Propeller.

These are all neat and all, but it brings up the next question (which answers different for different people).

What of the 6502 project is attractive to you? The hardware or the software? Is an ARM running a simulator adequate for your needs?

I harken it back to firing up, say, an old Sun workstation or something. In the end, you go through that work, and you get…a shell prompt. Depending on the era of the hardware, it's a SLOW shell prompt. Whee!

And I'm not trying to disparage anyone or anything, this is just the kind of stuff that I run into when playing around with this kind of stuff. It's why I ended up writing a simulator instead of building something.

Absolutely, we all have different aspects of our fascination with 6502 and maybe even different at different times. I've pasted things into a window on Linux which goes down a serial line to a Beeb, and I've typed at a Beeb keyboard to interact with a 6502 which is actually emulated on a Pi.

The Pi-in-Beeb is actually really nice - it's totally authentic for the whole of the keyboard, display, front end processor, OS, storage, even down the electrical interface to the second processor - and then the second processor is entirely emulated on a Pi, which is bit-banging the other side of that interface.

Yeah, that's kinda why pure nostalgia is best left in the past, where the spectacles are suitably rose-tinted.

I have an old Atari 800XL in a closet, as well as a ZX Spectrum (Z-80 CPU). I look back fondly on the 80s and the fun times I had with these little machines, but nowadays if I want to get my nostalgia on, I'll fire up an emulator. My kit is from the UK and I'm in the US, so it would be a little work to get the hardware up and running for real, but I actually have no desire to do that because, if I did, I'd have to wait for those programs to load from tape...

And wait...

And wait...

Back in the 80s, waiting for a program to load from tape (and potentially retrying on a loading error) was just what you did. Waiting five minutes or more... listening to those tones and screeches... was just normal. It wasn't slow (although "turbo loaders" were greatly appreciated), it was just how it is.

Now you load up an emulator and the software you want to run is in RAM instantly.

It's not a "pure" experience, but I'd argue it's a "better" one.


Some people still are still trying to minimize 6502 math functions, implement a better division algorithm, sort algorithm, game of life or perfect the FORTH "NEXT" word. That's all cool stuff, and a great intellectual challenge for people who are into it... but I've not come across anyone (as far as I know), who yearns for those screeching tones, long wait times and tape loading errors.

I'm sure they're out there, though...