micahcowan

Announcing Bobbin v0.4, an Apple Emulator. Why Yet Another Emulator? What does Bobbin do that Nintendon’t? Bobbin: Runs entirely in your terminal, using either standard input/output, or a curses screen display Can be used in shell scripts to accept typed text from standard input, and emit program output to standard output Can watch a program binary file for changes, and reload itself with the new program binary when it does, greatly accelerating development cycles for software on the 8-bit Apple Get it at https://github.com/micahcowan/bobbin/releases/tag/v0.4 Bobbin is distributed in source form only; you must be comfortable building software via ./configure && make && make install. I will not make myself available to help you build and install (unless it’s due to a bug). You also really want to have ncurses installed, unless you only want to use the standard input/output interface (no screen representation). Bobbin is written in C for modern, standards-conformant Unix OSes. It is tested on MacOS Ventura, and on Ubuntu Linux running under Windows WSL. Here are a couple of videos (of older versions) in action, demonstrating some key features:

Hi @newTIboyRob! In the video you mention, he most likely typed ESC again before scrolling with → to the T on the next line, and then ESC again before typing → after reaching that T. When you type → (while not in ESC mode), every character you move past while typing it is "typed" as the input on the current line. Including all those spaces. So yes, LIST automatically breaks those lines in odd places, and quoted string literals that get broken up that way will include all the spaces if you just type over all of them with →. Note that this only applies inside of string literals, or in REM or DATA statements. In all other circumstances, spaces are entirely ignored, and you can safely arrow past them without including them in your line. Hope that helps! -mjc

Hi @newTIboyRob - TL;DR: replacing your 20 PR#1 with 20 PRINT CHR$(4);"PR#1" is a much safer approach than just turning off the trace info with NOTRACE. The TRACE info is a symptom of the fact that you've disconnected ProDOS from its ability to process your program's output. This can lead to some bad things (but most likely just prevent you from doing File I/O in your BASIC programs. Since you only issued PR# and not IN#, ProDOS is still connected to INPUT, so the moment that you have a prompt to type at ProDOS will realize it's been disconnected, and should reconnect itself. If you were to use both PR# and IN#, ProDOS would wind up being disconnected from BASIC, and ProDOS commands would likely stop working, even after your program exits. Using the alternate PRINT CHR$(4) form I gave above lets ProDOS handle hooking output up to the printer, while still keeping itself safely hooked up to program output. ProDOS enables TRACE mode, under the hood, when BASIC.SYSTEM starts up, but it hides the trace output from the user, meaning you should never see it (unless you type TRACE yourself). Seeing it is a symptom that ProDOS has been unhooked from BASIC, and in some cases the command prompt itself. Hope that helps!

Check out this video demonstrating the basic features. Or this one demonstrating the new AppleSoft features. You can try it out for yourself in an in-browser emulator. In which case you should try reading the manual. And of course you can download disk images from the GitHub releases page. § Introducing a2vimode Hello, and welcome to a2vimode, which installs vi-inspired prompt-line editing facilities! Created for HackFest 2022, a part of KansasFest 2022 (an annual Apple ][ conference) Once the HELLO program is run (at startup if you boot from the disk), all text prompts that use the standard firmware prompt routine (DOS, Monitor, BASIC, BASIC Input), will start using vi-mode. With this software installed, you can: navigate conveniently within the line you are editing insert or delete text in the middle of a line choose between left-arrow/backspace or the DELETE key for erasing characters undo the last change you made to the input line easily jump to lines of an AppleSoft BASIC program, to edit at the prompt (see AppleSoft Integration Features in the user manual) You will also currently lose this feature from the standard Apple ][ prompt: including other on-screen text as part of your input The AppleSoft Integration Features (manual), and the "retype last line" command (CONTROL-L) are intended to shore up (and surpass) that feature for some use cases, but you may still find yourself missing it for some other situations. We apologize for the inconvenience.

@Newsdee I too have been using 8bitworkshop.com. It has some serious issues for professional development, but I have nonetheless found it to be the fastest path for me for Getting Shit Done®. The main reason for this is that the very instant I make a change, the code is quickly rebuilt and the emulator is updated with it - this makes for much faster code/debug cycles, particularly if I don't have to fuss with reloading a .dsk image. The major obstacle to using it, for me, was that I really needed a pretty genuine Apple ][ ROM, including AppleSoft, to do what I wanted. Fortunately, the current dev version of 8bws allows one to upload their own Apple ROM (or include it in their repo); if it's named "apple2.rom" then it will be used in place of the default copyright-unencumbered one. You can see how that works out in my project Taki, by clicking the 8bws link found there (it will automatically use the "dev" version rather than the latest release, which still doesn't yet include custom ROM support). My project bootstraps some BASIC code to drive the whole thing (the BASIC is stored as strings in a ca65 .s file though, heh). (My project is still a WIP, so doesn't do all that much - but most of the framework for doing things is now built, and it does do one or two types of text animation from within a BASIC program and with configurable animation parameters) True, you can't generate a .dsk, but for my part I'm happy running a separate Makefile in my local development directory to do that. I've also had some small discussions with Steven Hugg about approaches to doing .dsk generation within the IDE. While the addition of custom ROM support, along with some keyboard tweaks, allowed me to proceed just fine on my Taki project, I do foresee the following issues being a hindrance/burden to future development, unless someone (possibly me?) works to address them: The emulated machine is basically a stock Apple ][/][+. So, no DHRG, no DLRG (and no "any key pressed", either). Having the features of a ][e available would be very nice, and necessary for some types of projects. The IDE in general isn't really designed in a way to make it easy to customize the particulars of the machine under emulation. Currently the start position of your program is hard-coded (to $803). I work around this by putting a jump there to my "real" code start... The integrated editor sucks. Being able to generate a .dsk directly in the IDE would be a boon, as would be a more complete build environment, with minimal POSIX and "make" support. The latter's kind of a stretch-goal type of thing though... The GitHub support is rather basic. It'd be great to be able to keep source files in a subdir, for instance, instead of at the top level. And I'd really love to have recursive repository support; at the moment I have several sub-projects to Taki already (one for bootstrapping into AppleSoft for 8bws, one for 16-bit maths, and another for Forth-style stack manipulation operations in assembly); at the moment I maintain those in separate repos but then copy the files into Taki, which is pretty damn ugly, and could lead to unintended codebase divergence. But again, despite these major flaws, 8bws has proven far and away a much faster development cycle than anything else I've tried so far. Once I got used to doing things in 8bws, and got the minimum changes pulled into it that met my needs, I was able to really roll up my sleeves and get work done at a surprisingly fast pace. @Newsdee, you mentioned needing something you can use offline. 8bws can actually work just fine for offline, because it doesn't host anything on a server - it's all done using JavaScript and your in-browser storage. You can just use a Docker container or what have you to run your own instance of the webserver, and then you have access even while you're offline. Just be sure and sync your changes to your github repo before switching between the online instance and your private server (or, probably better, avoid using anything but your private server instance). The only thing that uses servers is that a cloud file storage account is used to temporarily host the files for a repo before uploading to Github. The 8bws sources currently include a configuration file that will use the same account that the production server does, so that too is taken care of for you.

Could it perhaps be Apple Graphics & Arcade Game Design by Jeffrey Stanton? The book seems to have a Defenders clone rather than Invaders, though (possibly it has both? I only saw the Defenders one mentioned in a synopsis, though). FYI, "extensively used sprites" is a little inaccurate, as no Apple II models has any hardware sprite support (unless the IIgs does? - don't know as much about those). But AppleSoft supported "shape tables", which had no hardware support but did have machine language routines to speed up their use well beyond what could be written from scratch in BASIC (but still required significant cycles to process, relative to true hardware-supported sprites). Unless you meant sprites the way we usually mean them today - just pixel graphics that we copy over and over again onto the screen. But at the time at least, "sprite" typically meant something where you didn't actually have to code how to draw it, because special chips would do it for you (NES and C64 had that; Apples did not). Whether this is the book you were talking about or not, it certainly looks like a fun read. Think I'll be checking it out myself! I know a lot of the concepts in there, but haven't actually experimented with all of them (in particular I've yet to do shape table stuff in AppleSoft), and this would be an excellent excuse to do so.

One straightforward solution I've missed is to print the number, and then separately use PRINT @n,... to print starting 1 character position before the current one, using CSRLIN and POS(0) to determine where that is. PRINT 77; : PRINT @(40*CSRLIN + POS(0) - 1), ")"

I get "BAD" printed first time I run it, before it gives the version string or prompts me for numbers of digits. However, I think the logic of your "BAD" test is reversed...? It fails if H (=HIMEM-FRE(0)) is LESS than your limit (0x9200-255, = 37376), which would mean you have MORE memory set aside than you need, and not less - doesn't it? Anyway, assuming I can proceed, I got 3.0625 for 100 digits, and 281.9609375 for 1000 digits. I then ran 100 digits again and got a slightly higher value of 3.06640625, and then ran 100 digits one more time and it was back at 3.0625. Could be interrupt or other timing interference I guess? Or maybe there's longer cleanup when the previous run was for a higher number? Anyway I figure that size of discrepancy probably isn't of interest to you. Currently running for 3000 digits, I'll update with that later. I added a 160 BEEP:BEEP:BEEP:BEEP:BEEP to grab my attention once the run is done, heh. Especially since I'm running the laptop off battery. ...Hm, I forgot to turn off sleep, guess that means the laptop's shutting off as soon as the program's done. Hope the display keeps the number when I turn it back on... Edit: The run for 3000 digits was 2529.4140625. I managed to keep the laptop on by hitting some keys for the input buffer to hold onto.

I've found that ? STR$(77)")" will print without the spaces. But of course you'd have to give yourself back some string space first, as your CLEAR 0 removes it. For N > 0, you can count the number of digits N has with INT(LOG(N)/LOG(10))+1. That's fairly expensive, computationally. But you could use that together with STRING$(X,"#") and PRINT USING. Finally, you could roll your own number printer.

I think another problem I'm encountering is that PINT doesn't work properly. As I noted in my first post, it produces an "OM Error" on line 30 the first time I run it, and then afterward proceeds to ask me for how many digits. But line 30 is where the .CO file would get LOADM'd, and since the CLEAR happens before that, the next time I run, line 10 will see HIMEM<40000 and assume everything is installed correctly - so I think it never is installed correctly, which would definitely explain why I get weirdness. CLEARing to HIMEM-FRE(0) can't be right, can it? That will use literally all available memory, which probably explains why LOADM triggers "OM Error" immediately after - it must have needed some of that! ...Also it looks like line 20 pokes some things into memory, before the CLEAR has happened (so we don't own it yet) - is this certain to be safe? I suppose if no strings are being allocated, maybe. I don't know much at that level of detail, but it makes me uncomfortable.

Yeah, I later saw the $8d00 and wondered at the 33,707 address. There is a high likelihood my testing was being interfered with by a present bug in REX#, a fix for which is currently being actively tested. I suspect the file system's entry was corrupted/pointed to an inappropriate place, and that would be why I experienced my issues. I didn't mean that the BASIC program should create a relocatable file - most such BASIC programs that I've seen, simply set HIMEM appropriately, copy the bytes to the expected location (in your case $8d00), and then SAVEM it. I didn't want BASIC so it'd be relocatable - I wanted BASIC so that I could clear all other files out that might collide with it, and _then_ create the .CO file (without even having TS-DOS installed to do it). However, this may not be necessary, as I think no collision should actually be happening between these files when the filesystem is intact. There is a file, CHANGE.BA, at the M100SIG Compuserve library (the filename is .BA, but its contents are untokenized ASCII, as all other files there are - rename it to CHANGE.DO if you're transferring via TS-DOS or the like; not sure what your emulator will prefer). This program can do what I need - I think you'd just select CAPINT.CO and run the ">Hex" command on it, and then attach the resulting .DO file here; it may make it easier for me to ensure I'm testing what you actually created.

Looking at the raw memory for the FS directory, I see that CAPINT.CO is installed to address (decimal) 33,707, while TS-DOS's start location is 33,106. I have my doubts that all of TS-DOS fits into just 601 bytes, so perhaps memory contention is the culprit. Unfortunately, I don't know an easy way to get your .CO file onto my Model 100 without using TS-DOS, without my rigging something up for the purpose, which is more time than I'm prepared to invest. Perhaps if you want to create a BASIC program whose function is to create the CAPINT.CO file (as seems to be a common way to distribute machine language binaries)? Then I could download both BASIC programs, unload TS-DOS and REXMGR, and then presumably run the BASIC program to install the .CO file.

I tried running your program, but I'm afraid I had no luck. I did a CALL 63012 on my (very newly obtained) REX#, which gave me REXMGR, and I then ran CALL 63012 again so REX would give me TS-DOS. I then removed the REXMGR menu hook with Ctrl-X, and KILLed REXMGR itself in case it might interfere with the .CO file (I also tried without removing those things first). I then ran TS-DOS, with LaddieAlpha running on a PC, and downloaded your files from the expanded .zip file: PINT.BA and CAPINT.CO via TS-DOS. I tried a few variations of this a few times, starting from a mostly-empty RAM filesystem (just a couple of small BASIC files; the last time I tried I removed those BASIC files first for no particular reason). Every time, the first time I would run PINT.BA it would fail with "OM Error" on line 30, not sure why. When I would run it a second time, it would proceed and ask me how many digits of pi, but when I run it with, say, 8 or 20 digits, it would churn for a while, then draw black lines on the screen, and hang until I would press the reset button on the back for a warm reboot. I've got photos of the screen here: https://photos.app.goo.gl/KBHa8iA1oRwGDNQ48 This was on a Model 100, with the REX# installed in the Option ROM slot.

A softswitch is just a "switch" that's triggerable by software; by reading or writing a particular memory locations (sometimes it matters which, and which value is written, others it doesn't - depends on the particular switch - they're all documented in the technical reference manual for the machine in question). So the POKE @The Usotsuki and I had mentioned is the softswitch. Writing a value to that location via POKE (any value - I'd said 1, @The Usotsuki said 0, but either will work fine - it's the fact of writing that matters, not the value) will tell the enhanced //e (and //c's, and IIgs's) to display the primary character set when FLASH is used, rather than MouseText. At least, if it's a normal one Does it? I'm surprised I haven't seen it documented in the Apple IIc Technical Reference Manual (Appendix F - Apple II Series Differences). Also, is it actually known to be unsafe to trip this switch on older machines? Do you mean specifically for determining if poke 49166,0 is safe, or just for checking whether the current machine is an Apple //e or higher?

Thought that might be a possibility! I believe this shouldn't happen by default, if MB is the first program you've run since last boot/reboot. I didn't run into this problem at all on my //c, whose MouseText behavior is supposed to work the same way as an "enhanced" IIe (nor in emulators emulating an enhanced IIe). By default it's supposed to be the case that flash mode is supported rather than MouseText, but something you ran before MB might conceivably have toggled MouseText on (80-column mode turns it on by default, but is also apparently smart enough to intercept "FLASH"-mode text when written, and transform it into "INVERSE" instead - at least on my //c). If you used ADTPro or the like to transfer the card to your machine, it wouldn't surprise me if that's what did it. Naturally, in this day and age, I shouldn't write code that assumes it was not transferred via some other program first (that may or may not have tweaked some soft switches), so I should probably "POKE 49166, 1" before invoking FLASH to be safe (or avoid it completely in favor of INVERSE instead - which I presume works fine for you in YOU/COMPUTER, and COUP FOURRE-marked cards?). I may still have more changes I want to do. It occurred to me the other day that you could totally play this game entirely with a paddle or joystick. I just got a MiSTer FPGA kit set up recently, and loaded it up to the brim with software and cores for various retro hardware, and I thought it'd be neat to be able to fire up and run the Apple II Mille Bornes on there, and do everything entirely via paddle (I'd need to build in a loop back to start at game end I suppose, as otherwise you need to type "RUN" again after the game ends).