Dear Apple-1 builders:
Bringing up many Apple-1 builds in the past eight months, I found it helpful to have a keyboard emulator cable in lieu of a real keyboard. The emulator may have an auto-typing feature so you don't need to type in the same diagnostics programs again and again and again.
I finally have found the time to put together instructions / plans on how to make such a keyboard emulator cable. I have built two based on these plans to a) snap photos and b) prove the plan has no bugs.
This is the keyboard emulator cable in action:
Here is the downside: I'm an old retired guy and I use old and ancient retired hardware and software. The plans come with the keyboard emulator software source code but it compiles under Microsoft C7.00 and runs under DOS. You also need a notebook computer (or a laptop) or similar of no later than 1990s vintage, because you need a standard DB-25 printer port into which the emulator cable plugs in. I have no doubt that some smart people lurking here on this forum could take these informations and make versions that run under Linux or even on the Raspberry Pi, which would be great.
If you do so, please post the results here in this thread.
And, all the attached stuff is placed in the public domain, so you can do with it as you wish !
Hi UncleBernie. I just found this in the older threads of this nice forum. That's really great! Thanks for sharing. I will definitely try this out at some point once my replica is working stable.
Is there a limit on the amount of text automatically typing in? Can this software maybe being used like a macro, i.e. for entering multiple commands for simulating the operation of the Apple-1? If so I can imagine to use this kind of setup for displaying an Apple-1 "in action" in a museum or on an auction...
Or just for fun on my next party with friends... ;-)
Indeed this is a great project! I will try it for sure, when i done with my replica build.
... it is not limited. If you press F3 on the notebook (or whatever), you get a prompt and then you can enter a filename.
This file then is opened and "auto - typed" into the Apple-1. The speed adjustment must be done such that the Apple-1 does not lose characters (the Apple-1 screen output rate is only 16.6ms per character, and the Wozmon may want to output more than one character for each keystroke). Speed adjustment is quite simple, it's one constant in the source code.
The software could be easily expanded to include macros. And, of course, it could type anything you want, if you change the code accordingly, which is easy, because it's C. You could make it auto-type anything you want. I still use it for both machine language and BASIC programs (and for auto-typing the BASIC interpreter into the machine).
Museums could use this technique to keep the Apple-1 busy so people could see how BASIC programs are entered and run etc.
But then, I think, you might want to add a sort of "Wait" character into the code, which just waits for a while (i.e. 0.5 second).
The Apple-1 keyboard does not have all ASCII characters, so any of the unsupported ones could be used to trigger a wait period, where no characters are auto-typed to the Apple-1, so it can catch up, i.e. when you run BASIC games, you need to wait until the slow BASIC is ready to ask for the next user input. All this is not very difficult, because real humans typing would also ponder a while before they make a move and hit a key. So just throw in some of these "WAIT" characters and you could even mimic irregular typing rhythm of real humans.
That would be fun !
If there would be more feedback on this thread, I possibly would write a Linux version of this program. It is easy to do but the direct hardware access needs a few added lines of code and then proper setup of the binary (it must run with root permissions).
I can do that but I think it may be a bit beyond the skill level of Linux newbies. This is why I posted the more primitive and user friendly DOS version first. The beauty of DOS (as primitive as it is) is that you can access hardware ports without much effort to get permissions from the OS. In DOS, there are no such permissions needed and anything goes.
@UncleBernie In another thread you mentioned that you added a "Turbo" feature for the auto-type function... Is this feature included in the source and executable linked above?
In post #5, Crud3 wrote:
"@UncleBernie In another thread you mentioned that you added a "Turbo" feature for the auto-type function... Is this feature included in the source and executable linked above?"
Uncle Bernie answers:
No, sorry, I've never updated the downloads on this thread. But you can have the source code, of course. Just send me a PM.
Here is some more info on how this 'auto-typing' and 'turbo-typing' works:
Both methods just generate automatic keystrokes to the Apple-1, and the data is coming out of a normal text file stored on the host system, character by character.
There is only one caveat: you may need to adjust the speed of the auto-typing slow enough so it does not overrun the Apple-1's capability to accept the keystrokes. I once had plans to provide the (open source) software with some control character sequences to set the speed (i.e. \s<number>) or do do a wait (i.e. \w<number>). But it seems nobody used this keyboard emulator it so why should I do this extra work ? For my own use I don't need these additions. It was in discussion for a while because a small private computer museum in Germany contemplated to show a "running" Apple-1 and then they could have used the autotyping to demonstrate the Wozmon, load games, let the computer 'play' the game, etc. This is much better, I think, than having a keyboard the visitor can type on by himself. Because this will not get him anywhere and most will walk away frustrated in disgust, which would leave a false impression on the Apple-1. So some "automatic demo" looked like a great idea.
What I have added since the posted version is automatic calibration of the timing loops to the particular host system (still DOS) and a "turbo" mode that loads kilobytes in mere seconds. This is again based on auto-type files which however issue WozMon commands to initialize the stack, load the ''turbo-type" loader, start this 'turbo' loader and then pump in the data at blazing speed (in this case only limited by the screen output speed on the host system as it runs a protocol there).
I have a tool running under Linux which turns 6502 binary files into such 'turbo' load files, fully automatic, and it includes a CRC checksummer so you know that the load was correct ... normally it will auto start but if the CRC was wrong, it won't and just return to the Wozmon.
In terms of effective bytes/sec this 'turbo-type' system is faster than my floppy disk controller which is as fast as the Disk-II !
I have lots and lots of such goodies but since my RQLT always is at a premium, I only have finished them just to the point that I can use them myself and they do what I want them to do for me. So there is no documentation, and the user interface is terribly primitive, and there are no user friendly features of any kind. Also, I've never figured out how I could replace obsolete download files on top of these Applefritter threads with updated versions.
If you still are interested, shoot me a personal message on my builder's gmail account and I will send you the newest source code and the exe for DOS. I still use the C7.00 compiler I bought around Y1990. It's one of the few Microsoft products that not a POS. Alone the thousands of pages of handbooks it came with are absolutely awesome. Allegedly, Microsoft used this compiler to develop the Windows OS of that time. It's a great compiler that never failed me, unlike many others that were around at the time. I remember one issue with heap management so I had to write my own library to replace their malloc() and free() but otherwise there were no problems I ran into. It is a robust compiler.
I typically write my C code such that it will work with DOS and with Linux but in this case there is no Linux version yet. It is a bit tricky to do bit-banging on the parallel printer port using Linux. On older versions you had to put your functions into the kernel and do a kernel compile run (hours), load, crash, rinse and repeat. Allegedly nowadays you can do this with a user program BUT you need to use the suid flag to run the executable in superuser mode. Not exactly safe ! At the moment I have no machine running Linux which still has a parallel printer port. A few months ago the hard disk died on that Y2000 vintage tower and this took the 2002 vintage Linux with it, and none of the newer versions I tried would want to run on this old hardware. It's an AMD Athlon based machine and somehow they must have lost the skills to make code that works for that, I think. The irony is that almost all the various Linuxes I tried to install (some hang during installation) appear to properly understand the machine's configuration, do a install, can be booted from the installation, and they almost work, but never good enough to compile a simple "Hello, Word !". Some people call this technical progress. I call it 'Idiocracy'. It seems that nowadays, getting Linux to run on any legacy machine (and even on some modern machines) is a total hit-and-miss exercise. Sometimes it installs fine and works, no complaints, but if it does not work, it is so frustrating and such a bad time thief that it ain't "free software" in the sense of "free" = cheap, and if this trend continues, then Linux will be utterly useless soon, on any machine. Which is sad because people will then turn back to proprietary operating systems made by greedy corporations, which are not open sourced, and spy on you, and send everything you type (your work) to the corporation, which is theft of IP, and maybe to the Gestapo, too, and all this is great evil in general we better should avoid.
As easy as following the written guide and solder it up... works really well with my old Sharp PC-5500 286!
"Typing" in Integer Basic from a file...
Then running Basic and "typing" in StarTrek from another file!
And finally running StarTrek!
Hi fans -
here is the updated version of the Apple-1 keyboard emulator executable. Unlike earlier versions it has a self-timing feature so the timing should be right all the time, regardless on which DOS based machine you run it. But since I have only a few computers running DOS, I could only do rudimentary tests. In case of difficulties you can always use the source code version at the beginning of this thread, but then you need a C compiler running under DOS.
Comments invited !
- Uncle Bernie
Half Jod done already. Just need to buy db25 press fit. For transistor i put the 2N3904.
I thing somewhere i have a Dos Machine with parallel port.
I have no words! What e great project ! Very easy to build, clever, and works great!
Thank you Uncle Bernie for this project. Thank you that you share all that projects and you are so helpful. Not many peoples share what they know!
I run A1KB software from diskette after bootable dos-6.22 as i dont have here a clear dos machine.
I hope you don't mind me doing this port Uncle Bernie... Since DOS machines are getting fairly rare, especially with a working C compiler, I did a quick and dirty port of your source to Linux.
I don't have a way to test this since I don't have an Apple 1, but the code compiles cleanly on Ubuntu using gcc. Theoretically a Linux box with a LPT port or maybe even one with a USB to parallel adapter might work with this. I don't have or use Windows, so I don't have any way to port code to that. It may also be possible to do a port to MacOS, but I haven't done much C programming there in a few years. I do now have a (relatively) recent Mac (Early 2009 iMac) running a not too ancient version of MacOS X (El Capitan). Anyway, not sure if anyone will be interested anyway, but if someone is, I might look at installing gcc on it and seeing what it would take to do the port.
I just noticed after re-reading the thread that you have or had plans to port this to Linux yourself. Anyway, I hope this helps. I have to give you credit that it is not often I run across code indended for antique MS-DOS compilers that will compile so cleanly on modern compilers like GCC. All I really had to do was supply equivalents to a few things to get it to compile on recent Ubuntu.
Hi Zijjel -
because you praised my keyboard emulator cable so much, here is a little gift for you to try out: the "turbotype" version of my 'Codebreaker' game:
The unzipped file should have the ending ".TUR" and it can be loaded using the same F3 function key as regular ".APL" files.
Oh, and please tell us in this thread if it works for you. So far I did not get much feedback about the "turbotype" feature and this is the reason why there are no more ".TUR" files.
Comments invited !
In post #11, softwarejanitor wrote:
"I hope you don't mind me doing this port Uncle Bernie..."
Uncle Bernie answers:
Great ! You are welcome ! Finally, somebody stepping forward and continuing my work. I've looked at your code and I see you have replaced the keyboard hit routine with the same one I found on the web for the same purpose (but never had time to do the actual Linux port).
The issue I have with Linux for this purpose is that the only older machine with a parallel port on which I have Linux running is a 80486 and the Linux is somewhat aged (Kernel maybe 1.3.8 ?). In these older versions of Linux you need to compile any code accessing the hardware directly into the Kernel, and a Kernel compile run is hopeless unless you did install all the required sources and tools back in the day. Only newer Linuxes allow the direct hardware access with the iopl() and ioperm() function family. And you still need to give the executable the superuser rights (chown root:root <exe_name>, chmod a+s <exe_name>). This is not without its perils.
All my newer machines with Linux don't have a parallel port anymore. Over the last year I made several attempts to install a 32 bit Linux Mint on some of my year 2002-2006 notebooks which still have a printer port, but all these attempts failed for various reasons, such as Linux not being able to set a useful screen mode or not finding the PCMCIA WiFi card, so I could not get the missing software into these machines. So far I have no "modern" Linux machine with a parallel printer port that works. And before my anger about all the complications and loss of my precious RQLT over FAILURES of incompetent programmers gets to a point where I would take the poor notebook into the backyard and blast it with a 12 ga, I stop, and get it out of sight (makes no sense to destroy a perfectly good notebook even if it's old and then spend the precious 12ga buckshot shells on top of it, despite it's tempting as such destructive acts greatly soothe the built up anger and frustration --- I know people who use to destroy failed electronic components which stole their time in a very methodical way using a hammer and an anvil, until just dust and crumbs are left, so the method is sound, and works, but notebooks are too large to do that).
This said, despite I tried, currently I have no Linux machine on which I could try your work. Oh, and it's the older version without the self timing and the turbo-type system. I can give you the DOS source code for this newer version if you send me a PM.
I think that I might have a running Linux machine with a parallel port soon, as from time to time, when my anger has cooled down, I return to these attempts to get one running. But it's not easy - the older the machine is, the more problems the more modern Linuxes have, and the newer machines where Linux Mint installs and runs like a charm are USB only. So sooner or later some USB based bridge to the ancient Apple-1 would be necessary, but as far as I am concerned I hate that idea due to the need to use a microcontroller with an USB peripheral. These come and go and it absolutely sucks to put RQLT into a project where they discontinue the particular microcontroller a few years later. It happend to me so often that I refuse to engage in any such projects. I try to use components which are less specialized and abundant so as to avoid becoming prey of usurers and extortionists. Just look at the situation with the rarer ICs used in the Apple-1. It's a disaster. These usurers have smelled the "blood in the water" and now want moon prices despite they are sitting on thousands of these parts which they will NEVER sell to the only market for these parts left: the Apple-1 builders. The same thing also happens with more modern ICs. Once an IC is discontinued, the greedy IC brokers start to demand usurious prices and crafty Chinese start to make counterfeits. So you are well advised to avoid modern ICs, too, if you want a project that can still be built in 10, 20 or 50 years.
Comments invited !
I have an older Thinkpad with a parallel port (also a 486 I think) and running an older distro (circa 2005-ish I think). I'm not that familiar with Mint, I mostly use Ubuntu these days although I've used everything from Yggdrasil (1993) to SLS, to Slackware, SuSE, Red Hat, Mandrake, etc. over the years. I've also had a fair bit of experience with other distros like CentOS, Arch, Raspbian, etc. over the past few years. If I get a chance I will see if the code will compile there. As for distros that will run on older hardware, I've had decent luck with distros like Xubuntu and Lubuntu on machines that don't have sufficient graphics hardware to work with the more mainstream distros. There are other distros which have even more modest requirements than those.
Another possible angle for this kind of project that might be easier to support long term than parallel ports on x86 machines would be using something like a Raspberry Pi which has easily programmable GPIO ports that could be wired up to the Apple 1 keyboard port. Those little machines are actually reasonably powerful, especially considering the small size and low price.
R.I.P. Bob Widlar.
In post #15, robespierre wrote:
"R.I.P. Bob Widlar"
Uncle Bernie adds:
Yes, Bob Widlar seems to have started it. But the method, once invented and seen, was (and is) very useful, so it spread throughout the company (and other semiconductor outfits). There is a deeper reason behind it. Not only does the act of destroying the offender provide satisfaction (this is why duels were popular before they were banned by law) but in the environment of an electronics lab destroying bad components prevents them from ever getting into another "lab rat" again. So in my lab, I do destroy all bad components immediately after they have been identified. But not with hammer and anvil. I just bend the pins of IC in (so they look like a dead spider) and from other components I snip off the leads right at the body of the component. I rarely use SMD which looks like dust anyways, and have no method for them.
The only exception of this rule are the bad ICs I fish out of the Apple-1 kit production process. These I keep in the "graveyard" on top of one of my monitors. This is because after I am done with the kit production, I want to make statistics which ICs did fail most often. This will be interesting.
You know what might be a good Linux system to run this sort of thing on? A Raspberry Pi.
At least I'm assuming that the Pi's GPIO pins could interface with the Apple 1 keyboard input given a bit of engineering work. You could possibly even power the Pi right off the +5v pin on the connector.
I agree... in fact I suggested the exact same thing a couple of posts ago in this thread.
However, I would NOT recommend powering a Pi off the Apple 1 keyboard +5V... it would probably draw WAY too much power... Pis are somewhat notorious for not always being happy with 500mA power adapters. They like a lot of juice. Like it is often generally recmmended to use a 2A 5V adapter.
Hello Uncle Bernie.
Keyboard backspace work somehow in your code?
In post #19, Zijjel wrote:
"Keyboard backspace work somehow in your code ?"
Uncle Bernie answers:
Keyboard backspace only works for the filename after F3 is invoked.
The Apple-1 has no backspace. Its cursor can only move forward.
Try DEL (or 'delete', or whatever it's called in your country, opposite of insert) and the Wozmon should produce a '_' (underscore) for each character deleted in its input buffer.
Before the return the command line looks like: FE_F24
Hope this helps. Please send me a PM if you still think there is a bug. We do not want to clutter this thread up with a wild goose chase.
- Uncle Bernie
The Apple I doesn't really know how to backspace (the cursor position can only increase) so instead it has a "rubout" function that echoes an underscore (_) to the screen and re-sets the pointer to the input buffer so that the next key typed will overwrite the previous character in the buffer. The user must keep track of which characters on the screen have been thus "killed" by underscores to see what the buffer currently contains. This is how printing terminals such as teletypes worked, and the earliest "glass tty" dumb video terminals such as the TV Typewriter by Don Lancaster.
Of course there must be a way to get this rubout key code into the Apple I, so the keyboard emulator checks to see if DOS's keyboard read routine (_getch()) has returned a 0x00, 0x53, combination, signifying the DEL key on the PC keyboard (next to the INS key). It could be modified to use the PC backspace key at the cost of complicating the code a little.
edit: I see Uncle Bernie has already answered.
The documentation for _getch() specifies that the "flag" can be either 0x00 or 0xE0, does this need to be checked also?
The code passes all ASCII codes unchanged, so BS does not get translated to Apple RUBOUT, only the (non-ASCII) DEL key.
One additional special key is the "left numeric keypad" which is translated to ASCII STX (0x02) or control-b.
As an additional note, in 1960s ASCII what is now the underscore character was rendered as a left-facing arrow (←). So keyboards of that era had a leftwards arrow key sending the code that the underscore key sends now. In environments (like Squeak Smalltalk) with a lineage to that era, the underscore key is used for the assignment operator, printed '←'. So it makes perfect sense that Woz used that character (by then rendered as the underscore we know today) to represent rubout (it was mentally, if not visually, a left arrow).
From inspecting A1KB.c, there appears to be a bug here:
If the length returned by strlen() is 0, the following line performs an out-of-bounds access to fname, and if the (undefined) byte there is 0xA, it overwrites it with 0x0.
In post #21, robespierre wrote:
"From inspecting A1KB.c, there appears to be a bug here"
Uncle Bernie answers:
there is no such bug. The if(!fgets(...)) before this piece of code prevents this to ever happen. Look of the definition of fgets() if you don't believe me. Well, if fgets() is compromized / was hacked, yeah. Bad things can happen if the library has been manipulated. But this is not fault of my code.
A quick question:
It is time for me to move on and put my replica in a nice wooden case with true keyboard. Can i have in 2x1 abaptor to use both keyboards? It would be a problem to have two keyboards connected (one is the emulator) to an adapter (2 to 1) and this adapter to motherboard? Permanently with a port on the back of the box.
In case that I want to display it with no hands on my Apple-1.
In post #23, Zijjel asked:
"Can i have in 2x1 adaptor to use both keyboards .. ?"
Uncle Bernie answers:
Unless you want a crude method with two 15 pin connectors at the back side and a jumper cable plugged in there to use the internal keyboard, you need some electronics. I think it could be done with 3 TTL packages. This would allow the use of both keyboards simultaneously.
If you are interested, please send me a PM.
- Uncle Bernie
A device could probably be made with a PIC or Atmega chip that would allow a parallel Apple-1 keyboard, a serial input and maybe even a PS/2 adapter all in one. Devices like the Appledore adapter already have a lot of what would be needed there.