APPLE-1 KEYBOARD EMULATOR CABLE PLANS

... 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.

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.

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

A1KB.zip

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:

codebrk.zip

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 ! 

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.

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.

Try this:

FF24<return>

Apple-1 responds:

FF24: A0

Now try:

FE<del>F24<return>

Before the return the command line looks like: FE_F24

Apple-1 responds:

FF24:  A0 

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

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.

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