Hi folks,
Today, v1.3.6 of The HoneyCrisp Emulator has been released!This update to my ECMAScript APPLE-1 emulator is substantial and includes a lot of great improvements and bug fixes.Here's a changelog for those who are curious:
What's New
Microsoft BASIC ROM Support
A new "Enable Microsoft BASIC ROM" option has been added to Settings under BASIC ROM Options. When enabled, Microsoft BASIC occupies the $E000-$FFFF address space (8KB) and is launched with E000R. Because the two ROMs share the same address range, Microsoft BASIC and Integer BASIC cannot be enabled simultaneously. That said, enabling one automatically disables the other, both in settings and when loading a BASIC program from the Program Catalog that specifically requires Integer BASIC. In this situation, HoneyCrisp Emulator now temporarily and silently swaps in Integer BASIC to run the program, then automatically restores Microsoft BASIC the next time the system is reset (a small on-screen banner explains this when it happens, similar to how Enhanced BASIC swapping temporarily for AppleSoft BASIC has in the past)...
Fully Accurate BRK / IRQ Vectoring
BRK and IRQ no longer incorrectly vector into WOZMON at $FF00. CPU.BRK() has had its post-vector-fetch logic removed. Previously, after loading the PC from $FFFE/$FFFF, the emulator would detect PC === 0xFF00 and either rewrite the PC by scanning RAM for a non-zero byte, or force-set wozmonActive to TRUE. BRK now performs standard 6502 behavior exclusively, which is as follows: push PC+2, push status (B set), set I, load PC from $FFFE/$FFFF.The now-dead returnAddr variable has also been removed, as it's no longer needed...
WOZMON Vector Table No Longer Clobbered
loadWozmonROM() has had three lines removed that manually overwrote the NMI, RESET, and IRQ/BRK vectors at $3FA–$3FF to $FF00 after the WOZMON ROM was already loaded. The ROM image's own vector table (NMI=$0F00, RESET=$FF00, IRQ/BRK=$0000) is preserved as-is. A duplicate copy of the same override in the boot sequence's krusaderROMDisabled branch, has also been removed because it was re-stomping the vectors back to $FF00 a second time after loadWozmonROM() already ran.
POST Vector Test Corrected
The IRQ/BRK vector POST ROM test's expected value has been updated from "non-zero" to $0000, matching real hardware.The old test had been written to validate the incorrect $FF00 behavior described above.
Compatibility Layer for Older Browsers
Testing v1.3.6 surfaced a rendering issue on older browsers.... a broken layout was observed running on OS X 10.14 with Safari 14.1.2 which was caused by the interface's Tailwind CSS not being understood by browsers that predate Tailwind v4 CSS support. HoneyCrisp Emulator will now detect a "dated" browser and automatically load Tailwind CSS v3 instead of v4, restoring a usable layout for backwards compatibility.
New File Loader Formats: .apl, .hex, .woz, and .tur
The main file-loader has been expanded with support for several new file formats, in addition to TurboType's .tur files described below: .apl, .hex, and .woz. File-type detection and routing has also been consolidated into a new central dispatchProgramFile() router, with detectProgramType() and detectBasicVersion() helpers used to automatically identify what's being loaded. NOTE: .woz is not the Disk ][ formatted file type.In the context of APPLE-1 emulation, .woz files usually contain WOZMON hex listings
Intel HEX (.hex) File Support
Added a proper Intel HEX parser (parseIntelHex() / loadHexFile()), so .hex files can be loaded directly into the emulator, including support for extended linear/segment address records.
BASIC Interpreter Selection Prompt
When loading a program from the Program Catalog that requires a BASIC interpreter, HoneyCrisp now shows a "SELECT BASIC INTERPRETER" dialog letting you choose between Integer BASIC, Applesoft Lite, or Enhanced BASIC, instead of silently assuming Integer BASIC. (So programs written for different interpreters can run properly from drag+drop.)
Ctrl+C Break Shortcut (Microsoft BASIC only)
Pressing Ctrl+C now sends a Break signal, equivalent to clicking the BREAK button.This shortcut is only intended for, and only works with, Microsoft BASIC.As such, it has no effect on Integer BASIC programs.
Program Catalog: Local Downloads
Programs in the Program Catalog can now be downloaded straight to your computer instead of only being loadable into the emulator.(Finally brought this back. lol) Each catalog entry has a Download button alongside its existing favorite and run controls, which fetches the program's file and saves it locally.
Program Catalog: Delete Button for "Custom" programs
If you add a program via the "+ ADD YOUR OWN PROGRAM" button in the program catalog, a trash-can icon will appear to the right most side of the entry, allowing you to delete the program from the catalog if desired.
JMON ROM Storage Optimization
The JMON monitor's program data, previously stored as a large WOZMON hex dump, is now stored as a base64 blob and decoded at load time.
Smoother Character Output Pacing
Character-by-character screen output now uses an accumulator (charOutputAccumulator) for more accurate print pacing frame-to-frame, and pasted text is printed at roughly 10x the normal typing pace instead of the standard rate.
Minor UI & Housekeeping
- The CFFA1 "unsaved changes" indicator changed from a
●dot to a(!)for clarity. - Documentation PDF links were updated to the latest revision.
- The KIL-instruction console warning now logs only once instead of repeating on every occurrence.(Which originally caused major slowdowns on the page.)
Cursor Blink Rate Now Follows CPU Speed
The blink rate for both the text cursor and the _@ startup pattern was previously fixed at a constant 350ms regardless of the CPU Speed slider. It now scales with the selected speed multiplier, so the blink speeds up or slows down along with the emulated clock.
Blink Rate Safety Cap
To prevent the blink from scaling into a flicker range that could pose a photosensitive seizure risk at high CPU speeds, the blink interval is now clamped to a 250ms minimum (never faster than a 2Hz full on/off cycle), no matter how high the CPU Speed slider is set.
Uncle Bernie's TurboType Data Transfer Protocol
Added support for .tur files, implementing Uncle Bernie's TurboType two-phase loading protocol. .tur files are now routed to loadTurFile() from the main file-loader dispatcher, alongside the newly-added .apl and .hex handlers and the existing .bas handler.
- Phase 1: Emulator auto-types a "Stack Sanitizer" at
$0003, then the Turbo Loader at$0100, both via keystroke injections which matches how the loader is bootstrapped on real hardware. - Phase 2: once the loader is resident and running, the
T / Xpayload block is fed at full speed through the emulated UART ($C300/$C301), bypassing WOZMON's echo loop entirely for a faster transfer. - CRC-CCITT (XMODEM variant): this is the verification of data transfer. If CRC-CCIT fails, EE is displayed on the monitor.
- Loader residency tracking: a second
.turload in the same session detects that the Turbo Loader is already resident and skips straight to100Rinstead of re-typing it, matching real-hardware behavior. - Backward compatibility: plain address:bytes
.turfiles without explicitT/Xmarkers are automatically wrapped into a synthetic T-to-X block, so older files still load correctly.
Program Catalog Additions
- ASCII to HEX Printer (originally by Tom Owad)
- Apple Computer Letter (a digital letter to Apple Computer Company written by Dean W. Phillips)
- Intruder (originally by guibrush of applefritter.com)
- Pascal's Triangle Generator (originally by Landon J. Smith)
- Timberman (Tape) (originally by zapcurcuit of applefritter.com)
The HoneyCrisp Emulator Technical Documentation has been updated!
This revision (F4) of the technical documentation fixing minor formatting issues and changes out the ASCII map reference for the one featured in the SIGNETICS 2513 datasheet/manual.
It is included with this release of HoneyCrisp Emulator.
Bug Fixes
Clock Frequency Calculation
Fixed a bug in the Clock Frequency readout where the reported kHz value was computed directly from the raw cycle count without dividing by the actual elapsed time, skewing the displayed number whenever a measurement interval ran slightly long or short. The calculation is now properly normalized against elapsed seconds.
Clock Frequency Throttled During Rapid Printing
Fixed a bug where the emulator's actual execution speed and the displayed Clock Frequency would drop sharply (down to single-digit kHz) during any print-heavy output, such as the Apple 30th Anniversary program demo, regardless of the CPU Speed slider setting. This was caused by a fixed video-queue back-pressure cap (VIDEO_BACKPRESSURE_CAP) that stalled CPU execution almost immediately every frame once a couple of characters queued up, independent of the selected speed. The cap is now sized relative to the per-frame cycle budget instead of a fixed constant, so it only acts as a safety valve against genuinely runaway output rather than throttling normal execution at higher speeds.BIG shoutout to @UncleBernie! Without him, The HoneyCrisp Emulator would not have TURBOTYPE™! Big thanks to @egrath as well! He provided me with a compiled ROM of MS BASIC for use with HoneyCrisp.HoneyCrisp Emulator 1.3.6 on Github
HoneyCrisp Emulator v1.3.6 at landonjsmith.com
Cheers,
Landon
Wow, good amount of changes! Thank you Landon!
Hi Landon -
praise for your great work ! And a few suggestions:
1. I don't think it's wise to use the canonical .WOZ file extension for something else, as this will only confuse users who are accustomed to WOZ files being Apple II disk images. I'd suggest you drop the .WOZ file support as .APL should do the same, just auto-typing in WOZMON command lines, or BASIC source code, whatever you can type on a keyboard.
When I started building Apple-1 clones, I had no way to efficiently load programs into the Apple-1, as the ACI in its original form never worked for me (later, my GEN1 and GEN2 improved ACIs brought remedy). So I developed the keyboard emulator cable and the associated software tools to turn binary files into WOZMON commands. In the beginning, I called them .WOM files (for WOz Monitor) but for some reasons I don't remember anymore its was changed to .APL, but it's the same thing.
2. There should be no output character queue of any kind, as such a thing does not exist in the Apple-1. What happens in the real hardware is that the cursor state machine signals a status bit to the CPU whenever it is ready to take another character. When the software then writes a character to the DSP port, that status bit signals that the cursor state machine is busy, and the software should not write any more characters to the DSP port until the cursor state machine has moved the character into the recirculating screen buffer, which happens at the cursor bit location that also recirculates. Since one circulation takes 16.6 ms, this limits the output speed to 60 characters per second. If you write software which ignores the status flag and continuously stuffs characters into the DSP port at a high rate, the output process mostly stalls, but the occasional character gets through. I've not fully explored this effect myself - it seems that the cursor actually may get lost under certain conditions, and then only can be revived by via the CLR SCREEN key, but I'm not sure if this can be reproduced on all machines.
With an output character queue you don't get an accurate emulation of this behaviour. This may be a minor inaccuracy not affecting most software but for a 100% faithful emulation of the Apple-1, the cursor state machine's behaviour in this borderline case of software abusing it should be modelled properly. But this requires more investigations on the real hardware.
3. When I tried my 'Codebreaker' game on HoneyCrisp v1.3.6, the game correctly detected that it's running on an emulator, and complained it wants to run on a real Apple-1. And advertises my Apple-1 IC kits ... just saying that it can detect it's not running on a real Apple-1.
So far my suggestions. I really appreciate your work and can't wait until HoneyCrisp also supports my color graphics card.
- Uncle Bernie
Your suggestions have been noted and will be implemented and/or fixed with the next release. Stay tuned.
Also, Bernie, how do you suggest I go about fixing Codebreaker detection of "real APPLE-1" hardware? How does the detection work?
Nevermind, I found it, and got it working. :-)
How was it done?
Let me guess: First reading a known memory location and storing it in a register. Then reading a memory location where neither RAM nor ROM is? On real hardware it should return (in theory) the last data that was actually on the data bus, e.g. the data from the first read.
In post #7, 'egrath' wrote:
" How was it done ? "
Uncle Bernie answers:
The 'real Apple-1' detection in 'Codebreaker' used a selectable register in the PIA which back then (years ago) none of the Apple-1 emulators had implemented. The game still would work, but it would spit out an advertisement for my kits (and indeed helped to sell a few kits). With the kits being sold out now, this ad is obsolete and a nuisance and I'm glad that both leading Apple-1 emulators (Landon's HoneyCrisp and Arnaud's POM-1 have now implemented the PIA more faithfully, so the ad never triggers.
IIRC, 'Codebreaker' also could detect the Replica-1 by checking for a 65C02 (all my kits and the original Apple-1 used the NMOS 6502), but I don't remember if I left this feature in. Codebreaker had two releases, the first one had a bug that crept in when I made it Apple II compatible, by zero page table address which shifted so the end of the table would cross the $80 threshold (2nd half of zero page). Since most games end before the table growing so big, my tests did not detect the bug.
Just for sake of completeness, I tested the W65C02S from Western Design Center in an Apple-1 and other than requiring to deal with some extra function pins (which are N.C. in the NMOS version) to be bent away and flight wired to the appropriate logig level, with the faster CMOS process producing fiercer current spikes in VDD/GND, a bypass capacitor of 100nF also must be soldered directly to to VCC/GND pins of the W65C02S.
This could be an alternative for Apple-1 clone builders who can't find NMOS6502.
- Uncle Bernie