micahcowan
-
Posts
24 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Community Map
Posts posted by micahcowan
-
-
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
HELLOprogram 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
DELETEkey 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.-
3
-
@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), ")"
On 11/30/2020 at 3:13 AM, micahcowan said: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.
-
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.
-
1
-
-
19 hours ago, vol said:
BTW do you know a way do not print a space after a number? I would like to print "77)" and I can't! I always get "77 )"
I use PRINT 77")". IMHO PRINT USING can't help too. I can only hope that there should be a special trick to do this.
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.
-
1
-
-
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.
-
1
-
-
15 hours ago, vol said:
Thank you very much. Sorry it is almost impossible for me to make such a Basic-program which should be able to relocate itself. CAPINT.CO assumes that it is placed at $8d00 address. Would you like to inform me about the start address of the RAM-disk on your system? I can change this address then and make a program suitable for your extended Tandy 100.
I can't understand why you have mentioned 33,707 ($83ab) address. First bytes of CAPINT.CO are $00 $8d. It seems that it is just placed at the first available RAM-disk location because $8d00 is occupied.
BTW for 100 digits, the program runs about a second. For 4 or 8 digits, it runs almost instantly.
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.
-
1
-
-
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.
-
2
-
-
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.
-
1
-
-
On 9/22/2020 at 9:06 PM, hloberg said:
the problem with the alt character set change on FLASH is only in the Apple IIe enhanced I have found. I know there is a soft switch that turns off the alt character set but I haven't got it to work for some reason. it's probably because I don't understand how soft switches work.
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
13 hours ago, The Usotsuki said:As I said, the softswitch is activated with "POKE 49166,0". If you want to make sure it isn't hit on a machine that doesn't know what to do with it, do "if peek(-1101)=6 then poke 49166,0" - it'll trip on the original //e, but it does have an effect there too even without the MouseText.
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?
13 hours ago, The Usotsuki said:("peek(-1101)=6" is a check used by Apple themselves.)
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?
-
1
-
-
2 hours ago, hloberg said:
good job! love it when someone can improve on what I do. In fact, I looking to retro some of the improvements in the previous versions for the TI-99, Atari MSBASIC and the CoCo2.
Thought that might be a possibility!
2 hours ago, hloberg said:oh, on my AppleIIe enhanced when you do a FLASH it pulls in the alternate character set with icons and the banner looks like gibberish. looks AppleIIe standard work fine though. not sure how that is fixed as I don't know yet enough about the IIe enhanced. I would imagine the IIGS would get the same effect. no big deal, just an interesting note.
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
INPUTto 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 ][ !
-
1
-
2 hours ago, hloberg said:
OK that's just weird. how I did this, and I do the same with all the ports, I use a program, in this case ciderpress, to import the text file I modified in Notepad+ as a BASIC file to the .DSK. on all other computers any lines out of sequence rights themselves when loaded the 1st time so I never bother to check. Well, learned with the AppleIIe BASIC looks like it will keep it out of sequence so I need to check that.
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).
QuoteLesson learned. More than likely there is no checking for lines out of sequence when loading a BASIC program in Applesoft. Applesoft must just assume they were all saved correctly.
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.
-
1
-
-
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 REM@@ 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 REM@@ 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/
-
1
-
-
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 REM@@@ 5 CARDS EACH 2900 PRINT
(BTW, is that REMark on line 2500 actually intended?)
-
1
-
-
So...it just occurred to me...while admiring the lovely controller i have always used.....that how many 2600 users, TODAY, have something in their hands or pockets that look a hell'ova like a Intellivision Controller....a SMART PHONE
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.
) -
-
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. ^_^
Yay, got one!
-
1
-
-
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.
I use PRINT 77")". IMHO PRINT USING can't help too. 
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Bobbin, an Apple ][ emulator in your terminal! Useful for accelerated software development
in Apple II Computers
Posted
Announcing Bobbin v0.4, an Apple Emulator.
Why Yet Another Emulator? What does Bobbin do that Nintendon’t?
Bobbin:
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: