Deja IIx

Keyboard handling is one of the last main pieces of code that I would like to get working this week. Unfortunately, it is not a straightforward process.

I’m hoping that some of the bits I’ve learned on that series of tubes known as the internet (thank goodness it didn’t get clogged up) will help in most of cases. I definitely don’t want to have to write m own USB keyboard driver! Regardless, the keyboard handling will have to be all new code.

I would also like to be able to put some throttling on the emulator so that it doesn’t run at full speed (cpu cycles) while it waits for you to type something. Deja ][ could suck up 95% of the CPU cycles waiting for you to press a key. Even though the non-debug emulation will eventually be in a thread, it will still need to hang out in a less intense way when waiting for user input.

Some other key items of note:

1. If anyone ever wrote a Mac plug-in, be warned that it will not work with Deja IIx. I am working on a more modern replacement of the plug-in design.
2. MouseText isn’t working quite right yet. Still tracking down the specifics on when it is supposed to be used when dealing with Assembly programs. I found the tech note when using BASIC though.
3. Serial Port native commands will simply be ignored.

Finally, work on Deja IIx will slow down after this week. My focus returns to several ongoing projects that are designed to pay the bills. That’s not to say it won’t get attention. I’m hoping that it won’t necessarily need as much attention.

Deja IIx was choking on me right at the loading of AW.INITS. That seems extremely strange. I ran the original Deja ][, worked like a charm. OK, so it must be something in the creation of the prodos directory (the code is all new to use modern OS X routines). After looking at the same code over and over again (and walking the same piece of Apple II code that scans the directory) I finally spot the problem. The storage type of the entry is looked at. What was 0x10 originally was changed to 0x1 (very subtle indeed). Bingo!!

OK, the emulator was no longer choking, but it wasn’t loading AW.INITs either (It was loading TimeOut code though). Hmm, very strange indeed. More coffee!! I need more coffee!! So I thought — hey, I haven’t run this on a PPC in a while (and theoretically it should just work). So I run it on the PPC machine and guess what, AW.INITs load up. The light bulb goes off!! There is a endian issue here (PPC stores words and longs in Big-Endian, Intel, and Apple IIs use Little-Endian). After more digging, I managed to find two very different byte swap issues dealing with the filetypes and auxtypes.

So I present to you, your first trip to the Main Menu:

Yes, inverse uppercase isn’t drawing correctly (and keyboard input doesn’t work yet), but we’re going from launch to the Main Menu on Intel AND PPC. That’s a lot of code that has to execute.

Speaking of execution. The emulation is running in debug mode, which basically checks various conditions with each instruction and uses a timer to execute on a regular basis. It does have internal loop that allows it to process a variable number of instructions with each “timer hit”. I cranked this puppy up (from 50 to 5000) and BAM!, not even 0.5 seconds from launch to Main Menu. It was literally so fast that some of the startup screens (AW.INITS, TimeOut) weren’t drawn before they were overwritten with the Main Menu. That was cool!!

With the debugger generally working (in read-only mode, no writing), progress has continued. In fact, the pace has moved considerably. The debugger helped me track down some subtle changes in the emulation that affected native calls.

Reading a directory does not currently work. Keyboard events aren’t handled. There are some performance issues with the screen display and the emulation. Lots of little things. Most of the bugs are now falling into the subtle category. Subtle changes with the emulation, native code handling, etc.

This screen shot is a sign of progress, not a declaration of success. There is plenty more left to do.

After a week at WWDC, I wasn’t quite ready to dive into the latest and greatest technologies (my brain is still processing all that information), so I decided to spend a little time on Deja IIx. You can click to see the full-sized images.

For fun, I thought I would show off some pics of the Debugger, which is pretty much complete. The console shows disassembled code, memory dumps and such.

Breakpoints can be set on when the program counter, when a memory address is read or written to.

Trace History allows you to actually watch every change made while the CPU is running, each execution of an OPCODE includes the current registers, CPU status. You can literally watch as loops unfold and data is accessed.

With the completion of the Debugger, the next step is adding the 65c02 opcodes needed to continue emulation.

Finally, note the subtle change in name (you did catch it in the first paragraph, right?). Due to the pathname issue, I decided to go with Deja IIx instead of Deja //x.

One of the changes that I think needs to be introduced with Deja IIx is some additional prefix specifiers.

Currently, the APLWORKS.SYSTEM is set to most likely live at somethng like:
/Volumes/Users//Library/Application Support/Deja IIx/

As you can tell, that is a very, very log pathname — and that’s just the starting point. Obviously , we have already have a special specifier for this location “*/”.

What this points out, however, is that files are likely to sit fairly deep in the hierarchical file structure on your Mac drive. This gets more complicated when you take into account that ProDOS name limitations are a fraction of the Mac’s.

So what to do. Well, I’m looking at adding additional special prefixes which can be set in the Mac environment. On the Mac side, these are always expanded out to their specified location, so matter where it sits on the hard drive.

So, you’ll be able to specify a path with something like “#01/filename.awp” and it will read the “filename.awp” from the location specified for “#01/” which will reduce a 60-70 character path down to 4 characters. Not all the details are worked out, but it should help mitigate some of the Mac HFS+ <-> ProDOS path issues.

This week there was a lot of talk about Time Machine. Of course, we’re doing our own variation of “time machine” with Deja IIx.

Unfortunately, while at WWDC, I had a hard drive mishap which wiped out my drive. I didn’t lose any critical data (it is all sitting backuped up at home), but it left me without code to play with during the week. Such is life. As they say in the world of physics when talking about theoretical time machines, you can only travel back as far in time as when the time machine was created.

Before all my data was wiped, I did manage to find the compiler problem that kept causing weirdnesses with the endianness (are there enoungh ness’s now?) with the emulator. And I managed to retain that info (it is a one line fix).

And theoretically, if all we saw at the Keynote is true, not only could Deja IIx due some fancy, very unnecessary graphical animations, but it could be a 64-bit app. Imagine your AppleWorks desktop reading 40GB of free space. Of course, I’m kidding – there is no benefit to the Deja IIx project to use 64-bit, but it is a big step for OS X (it is one of those things that requires a huge amount of engineering, is perfect for a relatively small group of people, but the majority won’t notice any difference).

I have managed to load APLWORKS.SYSTEM into memory and execute the first instruction (again). There are still some pieces not fleshed out in the ProDOS handling, but you got start somewhere.

More importantly, I’m finishing up the work on a new debugger which will allow me to step through the Apple II instructions, set breakpoints, view memory and disassemble the code. The Apple II debugger code is about 80% complete. The Apple II debugger is a necessary part to validate that everything is working (and track down the code if it is not).

Also, I was having some inconsistencies with the 65c02 emulator code I found, so I reverted back to the more stable 6502 emulator (I’ll add the needed 65c02 instructions myself).

Two steps forward, one step back.

Even though the code-name is “Phoenix, the Rebirth”, there is still a need to come up with name/version for the final product.

Would it be?

“Deja ][ 2.0”
“Deja ][ vX”
“Deja ][ 10.0”
“Deja ][ X”

No, no, no, no. After much contemplation, the name I went with is:

“Deja //x”

Much like Apple ][ became Apple //e, Deja ][ becomes Deja //x. The “//” hints at the more modern variation and the “x” suggests Mac OS X support.

Progress continues on Phoenix 2, but it is a much bigger project than I originally envisioned.

Obviously the file system is an important piece as AppleWorks cannot even load itself without it. Deja ][ relied on a native ProDOS emulation which actually reads the files via the Mac OS in response to the ProDOS commands. This allows files to simply reside on the Mac OS hard drive (no funky disk images to deal with). This will continue.

Unfortunately, the ProDOS support code needed a major overhaul. Most of the Mac OS system routines used by Phoenix are now deprecated. I’m now in the process of revamping all the Prodos file handling code to use the more modern OS X APIs.

This brings us one step closer to the first AppleWorks Classic launch under Phoenix 2.

One of the changes in “the Rebirth” is a brand new CPU emulator. This emulator was originally written by Marat Fayzullin and Alex Krasivsky. Marat has written several CPU emulators and his design shows. The design already incorporates the issue of Big vs. Little Endian Host vs. Emulated CPU.

Unfortunately, their CPU is only a 6502 emulator. I figured that I would have to make up the difference (As I recall, AppleWorks 5 requires a 65c02). Luckily Steve Nickolas and Holger Picker took the M6502 emulator and added the 65c02 opcode changes.

Will this result in improved performance? It is hard to tell at this stage.

It also adds some additional work. The tight coupling to the CPU in the native routines has to be changed to use accessors (so it doesn’t have to directly know what the CPU or memory looks like).