micahcowan

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

I made a bunch of modifications (improvements, I hope?), and released the results on github. Download the .dsk image, or try it out online in a JavaScript Apple ][ emulator! The biggest gameplay change is to how Coups Fourrés work, bringing them more in-line with the original card game: After a Coup Fourré is performed, that player is left with a Roll! status (the Coup Fourré completely cancels out the action of the played hazard) The player performing Coup Fourré draws a card, then immediately plays again A Coup Fourré may only be performed immediately after the hazard it counteracts (Since Coups Fourré are a relatively rare occurrence: comment out line 3510 to begin each round with set cards, chosen to make it much easier to exercise/test how Coups Fourré work!) In addition to the gameplay changes, Coups Fourrés are now accompanied by more "flashy" messaging, and Safety cards that were played as a Coup Fourré are written in inverse text. Other changes: The scoreboard displayed at the end of the round is easier to read and contains the complete information. A round counter is displayed, at the start of new rounds, and during gameplay. Most prompts wait for any keypress, rather than using INPUT to wait for a Carriage Return. Discard prompt no longer assumes "Y" when the keypress was neither "Y" nor "N". Changed the shuffle algorithm (faster, and guarantees every card was swapped at some point). It is no longer possible to make a card selection "in advance" while the computer is making its play (input is flushed before prompting for a card). Thanks again to @hloberg for bringing this excellent (and apparently, fun-to-hack) implementation of the game to the Apple ][ !

The only reason I was able to catch the bug in the first place, is because I have the same kind of workflow, except that instead of using ciderpress, I was using deater's dos33fsprogs command-line tools, and they refused to tokenize the file back into an AppleSoft-format file again when it finds an out-of-order line. Similarly I found another error from happy tool strictness last night, when I attempted to copy/paste the code into that JavaScript AppleSoft emulator, which apparently does complete syntax checking before it ever runs (AppleSoft only syntax-checks a line when it's run): line 17540 had one IF statement remaining that tried to use an ELSE (it copy/pastes from the github version fine now though). An AppleSoft-format file seems to be a tokenized BASIC program, laid out in the file exactly as it appears in memory. I think DOS must just copy the stored, tokenized BASIC, byte-for-byte, from memory direct to disk, including pointers to elsewhere in memory (the link entries the start of one line to where the next one is). I'm not sure if it translates in the case that start-of-program isn't set to $800, but anyway yeah - Applesoft/DOS does zero checking of the program after loading. As I understand it, there are programs that will happily take advantage of this behavior: before saving you can set the "end of program" vector at $AFB0 to a higher value, creating some space; then you can stick some machine code in that newly-created space before saving your program, and interface to it via CALL() and the like; and the DOS will happily include it when saving and loading.

I've put up a project for this at github, with the author's permission: https://github.com/micahcowan/a2millebornes/ The direct link to the (HTML-ified) BASIC source code is https://github.com/micahcowan/a2millebornes/blob/master/src/mb.bas If you're wondering at the various instances of REM not being followed by a space, for instance the first line 10 REMMB010 and others like 3670 REMREM [email protected]@ DISPLAY INTERFACE... that's an interaction between the detokenizer I'm using to generate the BASIC listing, and the way tokenization is done in AppleSoft. In AppleSoft BASIC, if you type a line like 10 REM FOO, AppleSoft tokenizes the REM and then immediately starts copying the content, and includes that first space. When you LIST it back out, AppleSoft will emit a space after the REM... and then it will emit another one because it saved it as part of the content. In order to avoid this problem, the tokenizer I'm using made the choice not to emit an extra space after the REM... that way you can feed the source listing to the tokenizer, and then feed the tokenized version back into the detokenizer, and the contents will be the same. However, it also means that a like that AppleSoft's LIST command would output as 3670 REM REM [email protected]@ DISPLAY INTERFACE ends up with a REMREM at the start instead. If I should make any updates worth cutting a disk for, I'll put it at https://github.com/micahcowan/a2millebornes/releases/ (and in this thread as well). It's my intention to work over the Coup Fourré mechanic, to bring it more in line with how it works in the original card game, and to restore the value of holding onto a card for the chance to perform a Coup Fourré (currently not worthwhile, since you don't gain the extra turn afterward, and you still have to play a Roll! card again afterward). EDIT: Should you wish to try out the current "in-progress" version, however, you could always copy/paste the contents of https://raw.githubusercontent.com/micahcowan/a2millebornes/master/src/mb.bas into the JavaScript "AppleSoft emulator" at https://www.calormen.com/jsbasic/

Hiya! Welcome to the Apple II scene - I'm new here as well, got my //c about a year ago. Mille Bornes is a great game, I have it in a tin at home, and my first exposure to it was on the Mac, in the form of this game. I enjoyed playing your creation very much! There were no surprising or confusing gameplay aspects (at least, for someone who already knows how to play the card game). I did find that the card reading/shuffling portion had me twiddling my thumbs, wondering how long it would take. I added a progress status, and made the shuffle faster as well (by only randomizing one of the swapped cards, incrementing the other, ensuring every card gets swapped at least once but no more than 100 iterations, and half the random calculations). Feel free to incorporate one or both changes. My modifications are: 1950 PRINT "READING CARDS...":I=0 2300 PRINT I;" CARDS. SHUFFLING."; 2310 II=0 2410 FOR Z=1 TO I:B = INT(RND(1)*I) + 1 2420 II = II + 1 : IF II = 10 THEN II = 0 : PRINT "."; 2500 T1$ = CR$(Z):CR$(Z) = CR$(B):CR$(B) = T1$: NEXT Z: REM REM [email protected]@@ 5 CARDS EACH 2900 PRINT (BTW, is that REMark on line 2500 actually intended?)

This reminds me: my favorite Intellivision Lives! collection is the one for the Nintendo DS, as it very effectively uses the bottom touchpad screen as the button-pad (and automatically loads up the overlay!). By far the best way to play emulated Intellivision games. But yeah, overall, I'd say the old controller was losing, in so many ways. True the awful 2600 joystick required far more effort than it should, but the Intellivision pads were pretty nasty too. It's still annoying to me to wrestle with the disc. I'm surprised nobody mentioned this yet, but the chief problem with the disc, to me, is all the dead spots (and it's not just a matter of poor software implementation - the buttons have gaps and don't reliably press down unless you're directly over them on the disc), and constantly adjusting the angle of your thumb until it's properly connecting with the button underneath is a right pain. The fact that, occasionally, I'll be running along in Night Stalker and want to corner, and stop dead for a fraction of a second while I angle things just right to get into that passageway, is something I just shouldn't have to do! The overlay system really didn't work too great, either, as inevitably the edges of the overlays would blunt up, and be a right pain to slip into the controller. Usually once you'd gotten familiar enough with a game, you'd just stop bothering with overlays, I guess. I never played Utopia without 'em, though (Hi, folks, my first post here in the Intellivision section, just been lurking. )

If there's a list, I want to be on it as well! ^_^

Yay, got one!

It's a shame these sell out so quickly - but I can certainly see why! I'm currently on the waiting list for the next batch, whenever that will be. Does anyone have a spare they'd be interested in selling me? I promise to put it to good development use. ^_^ I just received the MATEOS kit today, but unfortunately I can't get the burner to work so far (I was very careful to follow all instructions and the FAQ, with particular attention to OSes that automatically generate hidden files that confuse the device). I've reached out to Mateos concerning that, but SD card + menu would sure be convenient, regardless of whether I get the Mateos burner to work.