| Attachment | Size |
|---|---|
 POM1 1.8.6 for Windows | 5.41 MB |
Hello everyone, Arnaud here,
As we hit April 2026 and celebrate the 50th anniversary of the Apple-1, I wanted to share a major architectural update to the POM1 emulator (v1.8.6).
Some of the veterans here might remember the older Java iterations of POM1 from years ago. While it served its purpose, I have closely followed the feedback on this forum before starting to write the new version and realized the old architecture was creating bottlenecks for serious software archaeology and hardware cross-development.
Before diving into the new specs, I want to explicitly thank Uncle Bernie and Jeff Jetton. Uncle Bernie, your work on Codebreaker highlighted a severe limitation in the old POM1's keyboard entry. Pasting large .apl hex dumps was painfully slow and prone to dropping characters because the emulator couldn't properly bypass the PIA polling limits in real-time. Jeff Jetton, your early tests with your 15 Puzzle ASM code exposed execution bugs where the emulator would fail specific branch executions.
These historical failures drove this complete rewrite. The new POM1 is built from scratch in modern C++ with a focus on determinism, low-level accuracy, and large hardware extension support.
1. The Core: Cycle-Accurate 6502 & Clock Math
The engine is no longer a naive state machine. The CPU (M6502.cpp) is now cycle-accurate, executing memory fetches and addressing modes with strict clock cycle penalties.
The system clock is mathematically derived from the NTSC color subcarrier frequency.
f {CPU} = 14.31818 MHz /14 = 1.022727 MHz
This ensures that tight timing loops in native ASM should run exactly as they would on original silicon.
2. Resolving the Keyboard & ACI Bottlenecks
To fix the pasting issue, the KeyboardController now features a direct-injection clipboard buffer. You can paste modern code from your host OS, and the emulator will feed it to the Wozmon deterministically without overflowing the simulated PIA. You can use "telnet localhost 6502" too with P-LAB Terminal to feed POM1 if you want to have a full history of your interaction.
For the Apple Cassette Interface (ACI), CassetteDevice.cpp now features pulse-mode playback logic. It decodes .wav, .mp3, and .aci audio files asynchronously, feeding the analog wave simulation directly into the ROM reading routine.
3. Hardware Extensions & Memory Topography
The original 4K/8K memory map is fully supported, but POM1 now acts as a comprehensive Apple-1 development chassis. The PeripheralBus.cpp handles dynamic dispatching for an array of community hardware. You can toggle these via UI presets or CLI flags:
Storage: Rich Dreher's CFFA1 and the Parmegiani's P-LAB microSD interface (virtualizing a FAT32 file system directly mapped to a local host directory for easy drag-and-drop compilation).
Video: Uncle Bernie's GEN2 Color Graphics Card (simulating NTSC chroma artifacts for color generation) and the TMS9918 VDP.
Audio & Comms: P-LAB A1-SID (with
libresidfpintegration for the 6581/8580) and a 65C51 ACIA-based Wi-Fi Modem bridging to host TCP/Telnet sockets.
The Fantasy Multiplexing Memory Map :
4. Lock-Free UI & Debugging
The UI is built on Dear ImGui. To prevent the GUI from choking the 1 MHz emulation thread, they are decoupled using lock-free atomic variables (SnapshotPublisher.cpp). This allows you to inspect the full 64K memory map, watch the Program Counter (PC) and Stack Pointer (SP), and edit hex dumps in real-time without introducing micro-stutters to the CPU execution.
Access & Call to Action
POM1 is fully open-source (GPLv3). It is true free software, as it was in the beginning.
Test it now in your Web Browser (WASM): https://habib256.github.io/POM1/build-wasm/POM1.html
GitHub Repository: https://github.com/habib256/POM1
Releases (Win/macOS/Linux): https://github.com/habib256/POM1/releases
I invite you to subject this build to your most demanding stress tests. Fork it, adapt it, or use it to bridge your modern dev environment with your physical Apple-1 builds.
Happy 50th, everyone.
— Arnaud.
Hi Arnaud,
thanks for this work ! I appreciate this contribution of yours very much !
An updated POM-1 emulator with the support for my Apple-1 color graphics card will help me greatly to develop some software for the card. So far I did all the development work for the graphics function library using an Apple II emulator (Linapple). And these do not feature the dual video output of an Apple-1 equipped with my graphics card, but this is a nice feature I want to use with my software. It has advantages ... games could show text on the Apple-1 native "terminal section" and then could show graphics from the graphics card on a second (color) monitor.
There are, however, a few changes which I had to put into the planned "release" version of the color graphics card, which you could not know about. Even I did not know about these changes until I had the PCB layout 80% finished. I ran into routing channel congestion and hence could not route all address lines as planned to the address decoder for the soft switches. I had to drop some and this would have caused the ACI operation to interfere with the soft switches, which in the original Apple II are in the address range $Co50-$C057. I had to drop A6 from the decoder and this mirrors the soft switches to $C010-$C017. Alas, the wicked code Woz wrote to write to cassette toggles the TAPE OUT flipflop by using a LDY FLIP,X command (on location $C1EA in the PROM space). Where X is the double bit counter initialized to $10 and FLIP is $C000. Which means that any cassette write operation using the firmware will touch soft switch SS_TEXT and clear it, turning off the TEXT mode. Not good !
The deeper reason for this is that on this side of the layout, I do only have address lines A9 and A11 available and all the other address bits must be taken from the multiplexed address bus for the DRAMs, which is available in that side of the layout, as the video scanner resides there. Alas, A6 is not available in the ROW address of the DRAM. Where it ought to be because the soft switches are clocked at the end of the ROW address gate time. There is no way to change this. Initially, I had A6 routed to the left side of the layout, but then had to use this trace for some other, more important signal.
All this can't be investigated with the wire wrapped "lab rat" as it occupies the sole slot, so there is no ACI which could cause trouble with the soft switches. I found out about the problem when pondering over the consequences from dropping A6 from the decoder.
The solution to avoid all that trouble with ACI conflicts was to move the soft switches of the graphics card to $C250-$C257. So to adapt Apple II software to this graphics card, a little bit of additional rework is required to change all the $C0 of the graphics mode soft switches to $C2. All the text and graphics modes and the screen buffer addresses as such stay the same as in the Apple II.
There is one benefit from this last minute change of the soft switch addresses, though: now, access of the soft switches does not toggle TAPE OUT of the ACI. This means TAPE OUT can be hooked to an audio amplifier driving a loudspeaker and the sound effects of Apple II games can be heard ! There is a caveat, though: all the accesses to all other soft switches in the address range $C000-$C0FF (where the ACI reacts and toggles TAPE OUT) in the software must be knocked out. Only the accesses to $C03X (the "official" SPEAKER toggle soft switch of the Apple II) should stay as is. Then, the ACI will faithfully reproduce the same sound as coded into the original Apple II game.
There is another change from the original concept, I found out that "vaporlock" code from original Apple II games would not work in any case ... again, because the ACI spits us into the soup. "Vaporlock" works by reading "bit vapors" from soft switch addresses which do not drive anything onto the data bus. In the original Apple II, this is how lingering "bit vapors" from the video scanner accesses can be read and if special byte codes which make no sense for HIRES graphics are put into certain screen buffer locations, the "vaporlock" technique can deduce whether the electron beam is in the vertical blank period or not, and this info is then used to control screen page flipping or rendering small objects at times where the electron beam does not write them. An important technique for smooth animation without objects breaking up on the screen or "jerking" in weird ways the human eye can perceive and finds to be annoying. Alas, the presence of the ACI card foils this scheme. Despite I put considerable effort designing in "vaporlock" support. This was before I saw the issues with the ACI itself.
So I added a hardware flag which appears in the MSB whenever a graphics card soft switch is read. This can be used to discern horizontal and vertical blank periods using trivial and short software routines. It's a more powerful scheme than the VBL flag available from the IOU custom chip in the Apple IIc and IIe.
This said, it would be nice if these features would be implemented in the update POM-1 emulator. So people could start porting games from the Apple II to the Apple-1 ;-)
Comments invited !
- Uncle Bernie
Hi Uncle Bernie,
Thank you — this is exactly the kind of silicon detail I needed. I had modelled the GEN2 as a passive HGR
framebuffer at $2000-$3FFF with dual-monitor output, but I did not yet have the release PCB constraints: soft
switches at $C250-$C257, the A6 routing story, or the MSB blank flag replacing vaporlock when the ACI is present. Your note that vaporlock cannot work with the ACI matches what I had started implementing in my upcoming
Apple II emulator: POM2 (CRT beam position + blank detection). I plan to back-port that beam engine into POM1
and wire it to the $C25x reads so the MSB flag behaves as on your release card — not the legacy Apple II vaporlock path.
The TAPE OUT / soft-switch collision at $C010 is already visible in POM1 today (any $C0xx write toggles the ACI
flip-flop). Moving graphics switches to $C2xx will fix that in emulation too, and I will document the $C030-only
speaker rule for game ports.
Could you share a register map for $C250-$C257 (which bit does what, and MSB semantics for H-blank vs V-blank)?
That would let me match your release firmware rather than guessing from Apple II $C05x docs.
Arnaud
In post #3, 'arnaud.verhille' wrote:
" Could you share a register map for $C250-$C257 (which bit does what, and MSB semantics for H-blank vs V-blank) ?"
Uncle Bernie comments:
first of all, I'm glad that you will upgrade your POM-1 emulator to faithfully reproduce the features of my Apple-1 color graphics card ! This will help the Apple-1 user community a lot with porting / developing games for the Apple - 1 having that card. Which I hope will happen - theoretically, you could develop a game on the Apple II and then swap the video soft switch addresses and change the "vaporlock" based screen page flips for the code which interprets my flag (in the MSB of the soft switches).
I wrote some proof-of-concept "C" based code which detects the VBLANK period but I did not test the 6502 code on the real hardware yet - - - the MSB is not wire wrapped in, but the 74LS125 tristate driver needed for it is there (it's a leftover gate).
When I'm home again I'll put some information together for you and send it to you when ready, please allow me a few days, as I'm currently 100% occupied with finishing the PCB layout.
- Uncle Bernie
A TENTATITVE OUTLOOK ON FUTURE "PRODUCTS":
The next "missing" thing is about added hardware which, alas, is not developed yet . . . "Uncle Bernie's Apple-1 game port" or something along these lines. It will plug into the ACI and bring sound output and joystick inputs for up to two Atari VCS style (switch based) joysticks. I think these joysticks set the industry standard back in the day and they are quick and accurate in their response. They are "period correct" as they came with the Atari VCS. And the best thing about them is that there is a USB version still in production which can plug into a PC or notebook. I use one of them with Linapple to play the Apple II games I want to "steal" (idea wise) and then port to the Apple-1 with my graphics card. Of course, the "game port" will not use USB ... not "period correct" ... but the plain switch based "dumb" joysticks with the Atari 9-pin pinout are still abundant, and even the originals can be rebuilt using newly made parts kits from Best Electronics (www.best-electronics-ca.com)
Hi Uncle Bernie.
Take your time... such work needs time.
I'm adding the cycle-accurate video scanner (Apple II 65 cycles × 262 lines counter + MAME scanner_address floating bus) so that HGR game ports target the release card properly.
From your AppleFritter posts I understand the release board (a) moved the graphics soft switches to $C250–$C257, and (b) since the classic $C050 vaporlock doesn't work with the ACI present, exposes a blank flag in the MSB when those switches are read. I want to get this bit-exact and I'd rather not guess. Could you confirm or correct the following?
1. Soft-switch map. Is $C250–$C257 a 1:1 port of the Apple II $C050–$C057? My current assumption:
$C250│ GRAPHICS
$C251 │ TEXT
$C252 │ MIXED off
$C253 │ MIXED on
$C254 │ PAGE 1
$C255 │ PAGE 2 ???
$C256 │ LORES
$C257 │ HIRES
Anything reordered, dropped, or with different power-on defaults?
2. Read vs write. On the Apple II, any access to $C05x (read or write) flips the mode. On the release card, does a read of $C25x also toggle the mode, or is the read non-toggling / status-only (i.e. you decode R/W separately so software can poll the blank flag without disturbing the display mode)? This is the single most important point for me.
3. The MSB blank flag. On a $C25x read:
- Is bit 7 asserted during H-blank, V-blank, or both?
- Polarity — bit 7 = 1 while blanking, or 1 while active video?
- What are the low 7 bits — the floating-bus byte the scanner is fetching, zeros, or something else?
4. Video timing.
Does the card use standard Apple II NTSC timing — 65 CPU cycles/line, 262 lines, 40 visible bytes (h-counter 25…64), 192 visible lines — and assert the blank MSB exactly on those boundaries? If the release card differs (different active window, different VBL line count), what are the real numbers?
5. Second HGR page.
Does the release card support a PAGE 2 HIRES buffer mirroring the Apple II (i.e. $4000–$5FFF in the Apple-1 address space), or is it page 1 only at $2000–$3FFF? If page 2 exists, what address does it occupy and does $C255/$C254 select it for display?
6. Address decoding / A6.
You mentioned the release PCB has its own A6 decode constraints. Is $C2xx fully decoded to the eight $C250–$C257 locations, or are there mirrors/aliases within $C2xx (the way the Apple-1 PIA incompletely decodes $D0xx)? Knowing the exact decode lets me reproduce stray accesses correctly.
7. Multiplexing !! ACI coexistence.
With the ACI plugged, I assume the graphics switches at $C25x and the ACI at $C0xx never collide, and the old $C050 vaporlock is simply dead. Is that right? And when the ACI drives $C0xx during a video refresh cycle, does anything change on the GEN2 side (blank flag, floating-bus contents)?
8. Reset/power-on state of the display-mode latch — TEXT/PAGE1/LORES like an Apple II cold start, or something specific to the card?
That's everything I need to make the emulated release card cycle-accurate. POM1 is free and educational; I have already credited you for the hardware and I'll document the map. Happy to,share a test build once the beam-racing path lands so you can sanity-check it against the real board.
Thank you very much,
Arnaud
Hi Arnaud -
I've sent you a PM with a link to a pdf which should answer most of your questions about the Graphics card.
I wrote it in the last days without having seen your post #5 yet, so I may have missed something, but it's funny that your <hcnt> counter seems to work the same way as I have assumed in the code snippet that is in the pdf to explain how the HST status flag works. The line counter is the same, too ... it counts from 0 to 191 for the 192 "live" scan lines generating visible graphics and all the higher counts are for the vertical blank period. Here is a status report on your questions:
Q1: answered in the text
Q2: only a read can change a soft switch. And the HST status appears in the MSB of the byte read. Write operations to the soft switches are ignored. This is the main difference in their functionality. If needed, by disconnecting a pin on the decoder IC, this difference would go away but writing to the soft switches then would flip them AND cause a bus driver clash on D7. Although this clash won't destroy anything immediately, on the long run, with millions of such accesses, small damages in the drivers may accumulate. The IWM has the same issue as it does not look at the R/W signal and any write to a "read only" register of the IWM will cause a massive data bus driver clash. Apple's own SmartPort firmware uses read-modify-write instructions such as ASL on these read only ports, and so data bus clashes happen often. Maybe this is the reason why so many IWMs die. But this is just a suspected possibility, not a proof of causality.
Q3: the HST flag model is given in the pdf. The lower bits read the floating data bus. Which typically is the "bit vapors" of the H-Byte of the address of the soft switch being read ($D2). But this is not reliable. So in the pdf I recommend to put random data there. To show rookie programmers that they do something they shouldn't do ;-)
Q4: Timing seems identical to what you wrote in the question. More details in the pdf.
Q5: Primary and Secondary pages both for the TEXT and the HIRES mode are fully supported and work identical to the Apple II graphics subsystem.
Q6: It's more complex, as there are many "mirror" addresses. Details in the pdf.
Q7: ACI will co-exist with the graphics card with no side effects and no clashes. I had to move the soft switch addresses for the graphics card out and away from $C0xx for that reason. And "vaporlock" is really dead. This is why I gave the card the HST flag readout.
Q8: Apple-1 RESET will not affect the soft switch status. The power up state of the soft switches depends on the type of PLD being used (there is a difference between GALs and PALs) but their internal power-up reset can't be trusted due to the unrealistic constraints of these primitive POR circuits in them - just read the datasheets. It's a joke !
So the state of the graphics card soft switches after turning on the Apple-1 can't be trusted and they must be initialized by the software using the card.
There is no real remedy within the hardware constraints I have. And adding a good POR circuit to the Apple-1 would be stupid because doing so will lead to trouble and user confusion: on power up, the Apple-1 text buffer is not initialized, and this causes the familiar pattern with the '@'. But anything that blinks on that screen are fake / false cursor bits. Any attempt to write to this mess will confuse the cursor state machine, leading to wild outcomes.
So the only proper way to do automatic POR on an Apple-1 would be to have a more complex POR circuit which first holds RESET active while clearing the screen and only when the screen is cleared, releases the RESET. Alas, the CLR SCREEN signal is not accessible on the slot or expansion bus. It's only on the keyboard connector.
My take on this is that this is just another one of the lovely quirks of the Apple-1. Users must learn to do the CLR SCREEN manually first, and only after that, hit RESET.
Hope you will have an upgraded POM-1 soon --- I'd love to have one running on Linux to continue developing the graphics routines for the card. At the moment I can't make any progress as the last notebook with a parallel printer port I have in my possession was damaged (bit D3 of the printer port). How this happens eludes me ... I have a pile of such notebooks whose printer ports were damaged in the line of duty (as a development tool, my keyboard emulator can download and upload software to the Apple-1 at high speed). See the irony here ... printer port D3 goes to a harmless looking PIA I/O pin. Which is in input mode most of the time. How could this ever damage the output driver of the parallel printer port ? Strange. These parallel printer ports were specified to drive very long printer cables with lots of inductive overshoots and undershoots possible and various power up / power down / hot plug / hot unplug / ESD hazards. Consequently, the very first CMOS based parallel printer ports were utter crap and died like flies. And then came the redesigned, "hardened" ones which were advertised to be indestructible. But the Apple-1 PIA manages to do this ... maybe the Apple-1 does not like modern notebooks and seeks to kill them. Inhabited by evil spirits from another dimension which were summoned by the $666 price of the Apple-1 originals maybe ? Stephen King could sure turn this idea into a bestseller horror story. But I don't believe in ghost stories. It must be some perfidious electrical mechanism which kills those printer ports. But so far I could not measure anything suspicious. And some of these ports died on my lab bench which is ESD safe and runs on an isolation transformer. It does not get weirder than that ! But the age of these notebooks (20-30 years) may also play a role. As they get harder and harder to find on places like Ebay I think it's time to abandon the keyboard emulator using parallel ports on vintage notebooks and go for a 100% software based emulation - POM-1, of course.
This is why getting an emulation of my graphics card into your POM-1 project is so important for me, and maybe for others, too. Because software development on the real hardware is tedious and inefficient. We are in the 21st Century now and ought to have better ways to develop software for the Apple-1 and Apple II. The "dream" SDK would be a powerful "C" compiler / 6502 assembler suite linked to a powerful and accurate emulator (like POM-1) being able to run automated regression tests for any software under development. So you don't need to re-play a game under development again and again manually, after every little change to the source code. Instead, the SDK should automatically compile/assemble/download the code into the emulator and then launch an automated test script. This is the way ! But it is not trivial to implement this kind of functionality. The reason for this is real time action games ... there must be a way how the automated tests can "see" the moving objects / state of the game and then decide which inputs (keyboard or joystick) are appropriate to test the game code in that phase of the game. I think that having that feature would require a "side channel" where the game itself feeds state info to a customized "C" program which implements the tests tailored to the game. So far I've not seen anything like this, but I'm not a professional computer game developer. I think there must be such methods because I can't believe that professional game development companies would actually pay humans to test play their games while these are under development. But this is another topic for another thread ... I hope that once you have upgraded POM-1, that people will see the opportunity to develop games for the Apple-1 which have no "competition". When it comes to action games, the Apple-1 is an empty canvas, waiting for software artists to fill it. No other vintage microcomputer offers that opportunity ... for all other microcomputers, there are thousands of game programs out there, and competing against them is very hard. On the Apple-1, there is no such competition. But it must remain a hobby - as there is no money to be made with any of that. Which also is a plus - because when no money can be made, no IP thieves or parasites get attracted to the producer(s).
- Uncle Bernie
Hi Uncle Bernie, Your PDF was exactly what I needed — thank you. It answered every single point, and a few I hadn't even thought to ask. The good news first: the release card is now emulated in POM1. Everything you described is in:
- Soft switches at $C250–$C257, read-only — a read toggles the latch and returns HST0 in bit 7; writes are ignored (no D7 driver clash, exactly as you insisted — and yes, I thought of the IWM the whole time I wrote that branch). I decode the full SEL = $Cxxx & !A11 & A9 & A4, so the mirrors across $C2/$C3/$C6/$C7xx (A4=1) behave like the real board.
- HST0 = 1 during H/V-blank, 0 during live scan, with the 0 notch in the 3-cycle colour burst — your hst0_state(line, hcnt) is ported verbatim, and the demo masks the notch by OR-ing two samples 4 cycles apart, straight out of your Listing 1.
- The low 7 bits return random garbage in silicon-accurate mode (the default) — your "put random data there to show the rookies they shouldn't touch it" recommendation, taken literally.
- Primary + secondary pages for TEXT and HIRES (page 2 HIRES at $4000–$5FFF via $C255), 65 cycles/line, 262 lines @ 60 Hz / 312 @ 50 Hz selectable, and the latch left in a documented-arbitrary cold state that RESET never touches — software must init it, just asyou said. The ACI keeps $C0xx; vaporlock stays dead and buried.
It renders beam-raced now, not a passive framebuffer dump: vertical band splits and horizontal mid-scanline splits — your flagship feature, the one that lets TEXT and graphics alternate on the same line.
A-1-CrazyCycle.jpg
To prove it, I wrote a demo: A-1-CrazyCycle. The name is a tip of the hat to French Touch, the Apple II demo crew who turned the vaporlock into an art form. It felt right: vaporlock is dead on your card, so the demo chases your successor to it — the HST0 flag — with the same cycle-exact obsession, on the very board where you buried the old trick.
It initializes every switch by reads (your Q8), shows a TEXT page, shows the UBERNIE picture, then opens a 168×64 window that bounces off all four edges, through which you see the TEXT page underneath — TEXT_ON read at the exact cycle the beam enters the window on each scanline, TEXT_OFF at the exact cycle it leaves. The HST0 sync is three stages (coarse VBL by double-sampling to mask the burst notch, a ±0-cycle phase scan, then a line lock), after which the frame loop free-runs at exactly 17030 cycles with zero jitter.
And because you told me to keep $C030 for the ACI (Q7), two voices play through the ACI TAPE OUT while the window bounces — a walking bass and a melody on a single toggle bit, a branchless sequencer riding the 65-cycle scanline slots — and the ACI records the tune as it plays, so you can quit with --save-tape and keep it as a playable cassette. Watching that little window hold its edges mid-scanline, with music, was the moment the whole thing felt real.
I'm sorry your keyboard-emulator rig is dead — that's no way to have to work in 2026. Let me give you the tool instead. I'll cut you a Linux AppImage release of POM1 (1.9.1) with the GEN2 card — a single self-contained file: chmod +x and ./POM1-x86_64.AppImage, no toolchain, no dependencies,nothing to install. That's the zero-friction way to just see the card running.
But for the work you actually want to do, I'd build from source instead:
git clone https://github.com/habib256/POM1cd POM1./setup_imgui.sh # one-time deps (apt/dnf/pacman)cd buildcmake ..make # → ./POM1./POM1Five minutes, and it pays off for exactly your situation: you get the full sources, including the cc65 source of A-1-CrazyCycle to crib from for your own GEN2 routines; when I push a fix you just git pull && make and you're on the latest the same day, no waiting for me to cut a new release; and you can even tweak the emulator itself — the HST0 model, a soft switch — and rebuild in seconds. That tight edit-build-run loop is precisely the thing the dead parallel port took away from you.
I'd genuinely love for you to sanity-check it against the real board — if you have a couple of go-to test cases, a known-good HST0 polling loop or a split pattern, point me at them and I'll make sure they pass before I send it.
(And the printer-port deaths — a D3 line that's "just an input" killing a hardened output driver still smells like latch-up to me: inductive kickback on a long cable forward-biasing a protection diode, the PIA momentarily sourcing into the port's ground reference. Evil spirits summoned by the $666 price is the better story, though, and I won't rule it out.)
You're right about the empty canvas. No competition, no money, no parasites — a pure hobby, which is the whole point. I've credited you for the hardware throughout, and I'll keep the soft-switch map and HST0 model documented so the next person doesn't have to ask.
Test it : https://habib256.github.io/POM1/build-wasm/POM1.html
Download it for GNU/Linux AppImage :
POM1-1.9.1-x86_64.zip
Have fun with A-1-CrazyCycle,
Arnaud
Hi Arnaud -
thanks a lot for your great work ! Alas, I missed your post #7 for a while as I always was in a hurry during the last days and looked only for a message from you ... not for a post on this thread. This was unfortunate !
I think that your upgraded POM-1 will be instrumental for many prospective Apple-1 software developers. There might be only a few (the facebook Apple-1 forum has only ~1200 members, from 8+ billion people on the planet, we Apple-1 aficionados really are a small group ;-) but those Apple-1 owners who decide to actually develop software for the Apple-1 will certainly enjoy the "empty canvas" it offers. And once my color graphics card is released to the public, software development for the Apple-1 becomes even more rewarding ! We can explore graphics game programming techniques from back in the 1980s on that "empty canvas" and I think this is exciting (at least for me) as it's a fun hobby and pastime to explore this ancient realm without the distractions from commercially released software titles. In my point of view, this is a very important feature, being able to create works of art (software games and "demos" are works of art !) on an "empty canvas" without the psychological pressure from being surrounded by thousands upon thousands of competitor's once commercialized software. So, if we create a new game or demo for the Apple-1, our work will not be measured against others, our work stands alone, and it is unique. And it can't be "stolen" and sold for profit by so-called "AI" which scrapes the internet and plagiarizes everything it can find. Because the Apple-1 microcosm is so small, in the order of 1200 people, that any attempt of IP theft from that realm is a futile exercise. just as an example for this futility, in post #30 of the graphics card thread:
https://www.applefritter.com/content/uncle-bernies-gen2-color-graphics-card-apple-1
'macnoyd' has written: " You'd be lucky if the board manufacturer you choose doesn't share the design with someone in China or Hong Kong. I've seen it first hand. " and although his concerns would be justified in case of a commercially viable product that can be mass produced and sold for profit, I'm quite sure nobody can make any profit from stealing my Gerbers for the graphics card PCB, besides the fact I'll make them available for download once they have been proven to work. And I'd appreciate if somebody would download them, have a reasonable number of them produced, and sell them on Ebay or elsewhere, so builders could buy qty 1 of these PCBs at a reasonable price.
But back to POM-1: I will download everything as you have suggested and see if I can compile and make it work on my Linux notebook. Then I will run it through its paces and give you feedback. Oh, and of course, I will test the A-1-CrazyCycle on the real hardware, too, once I have recovered from the zapped printer port (readers who use a keyboard emulator cable with their Apple-1 see the P.S. on this topic).
This 'A-1-CrazyCycle' demo is certainly useful to explore aspects of the real hardware, expecially how the four refresh cycles per scan line the Apple-1 'steals' from the 6502 code running on it may affect such schemes. These refresh cycles happen on the same four cycles per scan line of the on-motherboad video scanner but currently the color graphics card video scanner is not gen-locked to the on-motherboard video scanner, but the phase relationship is constant while the Apple-1 power stays turned on. There might be a software way to determine the phase relationship by exactly cycle counted probes of the HST0 flag, and once it is known where the refresh cycles strike, to compensate for the lost CPU cycles. Another alternative is to make the user move the phase out of the critical region manually, but this requires good eyesight and a good monitor for the Apple-1 video. Finally, I could add the ability to the graphics card to automatically synchronize the phase (of its scan process) to the Apple-1 video signal, but this would need replacement of the row counter PLD with a 18V8 or 18V10 (not 'period correct') and a flight wire on the graphics card and maybe on the A-1 motherboard, too. I've foreseen this scanner phase issue but I don't regard this as a pressing issue that must be solved now. More important is to build the PCB based prototype and then test it with the dozen (or so) Apple-1 I have at hand. I have designed in two options for the clock system (using a DIL-8 crystal oscillator on the graphics card, or, alternatively, tapping into the A-1 master clock) and if the latter option is used, all of the R,S,T "user" signals on the Apple-1 bus are occupied. And then, adding the automatic phase synchronizer has no signal for it left on the edge connector, and this means that one of the signals not used by the graphics card must be disconnected by a trace cut on the motherboard - which is something I wanted to avoid, the whole GEN2 graphics card design hinges on not cutting motherboard traces. If I would have allowed any trace cuts on the motherboard, the design would have been much easier.
I'll post here again once I got the 'A-1-CrazyCyle' demo running on the real hardware and show y'all a screenshot off the real TV.
- Uncle Bernie
MORE ON THE KEYBOARD EMULATOR CABLE DAMAGE
P.S.: as for the damaged printer port, I agree that it looks like latch up (measurements indicate that the D3 high side driver never turns fully off and leaks a few mA which ruin the "L" level) but how exactly that damage happened remains a mystery. The keyboard cable is far too short to produce any serious inductive kickback, and the power supply of the notebook has no line ground, which could have been the culprit: all these switchmode power supplies which have a line ground have - by design - a weak current "sneak path" from their supposedly insulated output voltage side to the line voltage side. The danger with this "sneak path" is that it only limits the current to and from the line voltage side to the output side to levels which are harmless for humans touching the output side, but there is no voltage limit, so anything connected to the output side of the switchmode power supply can get charged up relative to any "ground" which includes the floor. You can actually measure this "sneak current" from the output side of these switchmode power supplies to ground. So I avoided to have switchmode power supplies with line ground connections on both sides of the rig. This should avoid that the "sneak current" coming from one switchmode power supply flows through the Apple-1, through the PIA, into the keyboard emulator cable, and then into the parallel printer port of the notebook computer, and out through the "sneak current" from the switchmode power supply powering that notebook computer. You should be able to see now how the risk of damage comes about in this scenario. There is even a third player in this game, the TV into which the video card's output video cable plugs. This TV I use also has a switchmode power supply inside. Now, if there is only one line ground involved, no "sneak currents" should go into the rig and leave through another power supply ... except if there is other leakage / compromised insulation between the "hot" side of the various switchmode power supplies involved and their output sides. Now, with the TV and the notebook power supply being > 25 years old, all bets on good insultion are off, and bad things may happen. This is why any professional electronics lab has their instruments checked for proper insulation once a year and they get a sticker for that. AFAIK, I had no case where a printer port was damaged when the Apple-1 ran off transformers, the B&W monitor it was connected to also has a line voltage transformer inside (and no switchmode power supply !) and the switchmode power supply of the notebook was the type with no line ground. But this is only anecdotal evidence. I've spent hours with measurements to find the culprit for the damaged printer ports but could not indict and sentence to death (the trash can) any of these old electrical things. But I fondly remember a pre-WW II vacuum tube based radio which I had as a kid and this beast would mete out painful electrical shocks whenever its antenna cable was touched. Despite the antenna cable was insulated ... well, the insulation was a bit brittle and crumbly. I concluded that some other insulation in the radio must have deteriorated, making it electrically unsafe, and threw it in a dumpster. Would have been a nice museum piece unless somebody tried to power it up. Take this anecdote and the above writings about "sneak currents" as a warning ... our vintage computer hobby may be more dangerous as you might think, due to the aging electrical components in the power supplies. Never let your kids play with your vintage computer stuff, or at least have them under constant adult supervision, so they won't put their fingers on anything that might be electrically charged. The inherent risk with aged electronics also are a good reason to refurbish power supplies with new ones or even to build whole replicas using fresh electrical components. - Uncle Bernie
I got so excited about Arnaud's work on implementing support of my Apple-1 Color Graphics Card (see his post #7 above) that I put an electronic band-aid on my damaged parallel printer port - just to be able to load his 'Crazy Cycles' demo, and the outcome is this:
UB_CrazyCycle1.jpg
You can see that the Hires page with the 'Alien' and the Eiffel Tower is there, but the little text window did not appear as seen in the POM-1 simulation (see Arnaud's post#7 above how it should look). Instead, the text mode window spread out to a longer bar of text characters which rolls downwards in the picture.
So, it almost works, but not as expected, because something in the timing is not right. The most likely culprit are the refresh cycles of the Apple-1 which stall the CPU for four cycles per scan line, as I've explained in my previous post (#8 above), it might be possible to probe by software at which position in the scan line the refresh cycles strike and then compensate for it, but even if this would be viable, it's certainly a complicated algorithm, and it can't compensate for refresh cycles which would strike the exact CPU cycle where the soft switches should be flicked but won't (they would be flicked one cycle later). So even with the best efforts to remedy the issue, vertical screen splits could not be timed on exact horizontal positions. For the vertical splits I have in mind (vertical stripes of LORES graphics in HIRES screens, for a 'Codebreaker' game with colored 'pegs' in lieu of letters) this small uncertainty in the split location could be designed around (have a 'black' zone wide enough in which the soft switches get flicked) but for the stunning, cycle exact screen split demos of the 'French Touch' group we would need to turn off the refresh cycles of the Apple-1 motherboard. Which means we would need to turn off all the on-motherboard DRAM and use the RAM on the graphics card instead. This is doable but I hate the idea, it's such an awful hack to the Apple-1 I don't want to do it.
Alas, I can't investigate this refresh cycle topic any further at this time, since installation of 'git' and some other software needed to work with POM-1 did fail today, most likely due to unresponsive repository servers, or timeouts due to the public library WiFi being overloaded (as usual). So I'll have to wait until I can tap into a better WiFi somewhere else. No way I would want internet at home ... avoiding this trap and security risk may slow my work down, but this is OK for me, as I'm not working under a contract with a deadline to deliver a product. So be patient, please.
- Uncle Bernie