Your viewers might be interested to know that Lee continued to develop Toolbox 181, and with Dave Moorman ultimately created DotBASIC Plus, a full fledged BASIC extension. All of the features of Toolbox 181 are included, plus a lot more. The features are used the same way as in Toolbox 181, except with commands like .MENU rather than SYS addresses. Great video, as always!
Thanks Alan, DotBASIC looks great! By the way, I was just using the TRS-80 Model III I bought from you and a power supply capacitor released its magic smoke WHILE I WAS RECORDING :O !! Looks like I will have to finish that segment with an emulator now :) Look for that episode soon.
I have a copy of dotbasic myself. This episode inspires me to make a program with it! Now that I know how to autoload stuff it wouldn't be too big of a deal to make it "stand alone". I'd also like to see more stuff done with COMAL-80...but the carts are rare and expensive. I got one because I thought the language is just too cool not to have...pascal, logo, and basic + sprites, sound, turtle graphics, long variable name support all rolled into one interpreter with a full 30K free! I really like the modular approach Robin uses in his menu design. I fear that a more complex system with data statements might get really confusing when scaled up and such. I think a similar approach could be done more along the lines of 'Monster Battle' from the book 'Big Computer Games' by David Ahl. It uses subroutines for all the events. I can imagine just nesting the box routines inside the message and action routines for an easy engine.
@@peterlamont647 Merging all the parts of a DotBASIC program into a single executable program isn’t too hard, and the tools to do it are included in the DB+ package.
@@MrHowlinAlan Ya, I have been noodling around with it and it seamlessly links all the commands using the dev program. My question though, is how on earth do I load a project? It seems like it wants to make a new project every time. If you type in your old program, it kills the library file. If you load your program directly directly, it doesn't seem to edit properly. Any idea how to officially edit your existing program? I kinda got stuck there.
I loved Loadstar and even wrote a few crossword puzzles that were published in it. I purchased Loadstar Compleat years ago and have gotten many hours of enjoyment from it.The editorial content is an amazing look back through time.
Bravo! Well done! @10:08 - Abuse of the Kernal??? The slipshod 'LOAD"file",8,1' of BASIC 2.0 was an abuse of programmers! The underwhelmingness of BASIC 2.0 and the extraordinary abilities of the C64 pushed hobbyist coders to learn ML and create an effectively better language. The "bload" hack was the price of entry into the full ability of the C64 for many of us. The miracle is that this "beload" hack and dozens of other interior tricks were built into RAM so we could play with them. Thanks for the step-by-step breakdown of SYSie programming. You are the greatest explainer and demonstrator of historic technology!
Thanks Dave! You're right that BASIC 2.0's shortcomings spurred on many more people to learn machine language. You know all about that with many years of experience :)
A dude makes RU-vid videos about BASIC (and 6502) programming on the C64... A lot of people: WTF? It's ******* more than 35 years old..!!! Me: WOW! It sure brings back A LOT of memories! Thanx!!!
The way I'd hack that menu is to poke the desired number of CRSR downs into the keyboard buffer. I confess, I forgot where the keyboard buffer is. I suppose, if I remember correctly, you'd also have to poke 198 to the number of keys down, up to ten. That would work for any location of toolbox without having to corrupt it later. Of course, this is all moot if toolbox pokes 198 to zero. I'm surprised I didn't simply add a default menu item parameter, or at least a jump that included it. I can barely remember some of the commands. I totally forgot fancy lattice. I do remember coming up with BIG SCREEN for these types of games, but I don't think anyone used it except Fender once, possibly because of the lack of smooth scrolling. And also SAS ARRAY to help quick searchers, and I think sorting. It was more than 20 years ago. The last thing I was working on was a compiler language that converted text into ML-speed code that used a completely relocatable toolbox (based on the start of BASIC. It was getting complicated, and I ran out of time. I never got to finish it.
Thanks Jeff, great to hear from you! You're right about location 198, and the buffer itself starts at location 631. I should give that approach a try to see how it works. I forgot about BIG SCREEN, I need to dig that up sometime. That last project sounds really intriguing. You sure managed to write an amazing amount of code, and kept LOADSTAR Letter going for so long too.
@@8_Bit BTW, LOADSTAR's presenter was written with a modified toolbox... I think. I know I spent a long time working on it. These are twenty-one-year-old memories. I know wish I had jumped into assembler earlier. It just never clicked for me until programming god, Rick Nash nudged me. Toward the end, with the toolboxes, it was nothing to just write a whole program in assembler. I only really needed BASIC for complex math. I had a Super Snapshot of Ebud and toolbox in a place where I could both code and assemble and test. I also wish I had more graphics assignments. Never got to dip my toe into graphics and assembler, so I'm totally green with sprites and bitmaps on a C-64. I also didn't get to touch the C-128 side much and it always intrigued me. But, if I remember clearly, it was another Canadian who combined my toolbox with Mr. Mouse. THAT was my preferred programming environment.
@@Sentinel3D would you ever resurrect LOADSTAR to do more commodore stuff? There's a project trying to recreate the C65 now, as well as other projects that improve on the C64 (without making it something completely different).
@@cheater00 I'm more a user now than a programmer, and I'm writing and editing plenty of screenplays, plus working on some movies that I want produced before I exit this plane. Right now, I have a full-time job besides that. I can't see myself devoting much time to gearing back up to coding beyond the simple ML subroutine.
@@Sentinel3D than there is just one thing to say from us "little" consumers: Thank you very much for all your efforts and great work! Live long and prosper! 🖖🏻
As usual just amazing! Great to see and learn from your videos. Though I like to watch “review” videos of old tech, you just bring it to another level by actually programming on these old computers and explaining while doing it. Just great! Thanks and keep up the good work 👍🏻
You are totally awesome, and perhaps undervalued... what will the newbies do when they're old and AI takes over their memories... he he... yeah! You are very good on explanation, on experience, on knowledge, on presentation, on calmness, on pleasant 1 hour experience (for those who lived it and care). Cheers to you! I enjoy your channel and if i get some spare funds in these crazy times, you're first on the list of recipients! Thanks for the memories.
@@8_Bit It sure is a great hobby you have! I would love to see some of your C# stuff sometime though, be fascinating to see how your experience and practical knowledge of getting the very best when you have few resources applies to more modern* systems! *not necessarily better, mind you!
i was so happy the other day.. swedish librarys in the small town i live in discarded all older book and now have ZERO books about retro computers...although.. i got a library card and also got access to their database...and found lots of 64 and amiga books to be borrowed from the archives of other libraies in the country... a good tip for you who love hardcopies...i just ordered some books on amiga 500 after finishing the c64 basic book series =) if your library doesn't have it...ask for it and you shall find =)
Our libraries used to sell their old discontinued books through a "Friends of the Library" store in a mall and I managed to find some great books that way!
I love learning new things about the c64 (and other machines of the era). I've learned some really interesting BASIC from this and other video's. It is such a great utility writing language, I get these moments in the video where I think "Damn, that would have been so useful in the day". I used to code stuff in ASM but BASIC was always there for fast and quick dev when execution speed wasn't a necessity.. making tables.. disk/file IO.. data preprocessing etc. I made a menu system in the day, but it was slloooow.. I never got into making custom ASM/Library calls through BASIC, except the occasional DATA segment for quick and dirty stuff. I always treated BASIC and ASM as separate things, not mixing them. Thanks for the work and observations, Robin.
Cool to see the ML routines reading parameters off of the BASIC (2.0) SYS statement like that! I gather from a quick Google search that this is accomplished by calling kernal routines, and thereby supports literals, expressions (including BASIC variables), and error handling. Great for enhancement libraries for BASIC!
Yes, I should have given an overview about how that worked but I didn't expect the video to be so long as it ended up being. Maybe I can do a dedicated video to this technique in the future.
I highly recommend getting LOADSTAR COMPLEAT. There's tons of great content. I got my copy on CD back in June. Now, it's downloadable which is great so you don't even have to wait for shipping. You can't beat the deal for $18.
I wish I would have kept all of my LoadStar disks, I only ever had the 5.25" disks. I remember really looking forward to them coming in the mail and spending days going through each issue.
you know getting toolbox 181, dumping its "kernel" would be a good way for a very new Machine language programmer to get a lot of basic routines to add to their toolbox. just remember to credit :)
Love the video! I remember waiting for the latest LOADSTAR release to come out just to tinker with the contents on the disk. I shot over to the link you shared immediately and ordered a copy. Unfortunately, it's been several weeks and I haven't heard anything back. Hopefully, things are OK on their end. Keep up the great work, sir!
As always, fantastic video Robin - I really appreciate it! I have to say that I really love the way that you break down and demonstrate the techniques used in these applications ... I would dearly love to see a series of videos from your good self where you go through implementing different algorithms on the C64, especially if you could do that with more modern algorithms that weren't designed with 8-Bits in mind! Thank you again!
Indentation can also be achieved by using Shift+Space after the line number, followed by any number of spaces which will be preserved. Looks better than those colons, imho.
For those asking about JRPGs - Penultimate Fantasy is a mini JRPG on the C64, while Wonderland is more of a NES Legend of Zelda type game. Fascinating video. We used Lee Novak’s Mr Mouse in the Scene World diskmag outfit and I can see a lot of similarities to this Toolkit
I hadn't noticed Penultimate Fantasy, thanks for mentioning it! Yes, Mr. Mouse apparently shares a lot of code with this toolkit. Using it felt very similar to those days using Mr. Mouse, except for the mouse part!
Loadstar and Ahoy! were favs of mine, though I never had the money to do subscriptions back then so I only managed to pick up the odd one. Back when I was a actually messing around with C-64 coding, that menu system would have been challenging to understand. Now it's pretty straightforward; the basic is more annoying to decode than the assembler :D BTW, _super_ trippy ending maaaan. Cheers,
Man, Loadstar sure brings back memories. I had no idea that it continued so long into the future. That is some serious devotion, because I doubt they were making much money at that point. Pure love for the machine, like the people making modern games for it even now. Cool!
Absolutely! I love how the retro-scene has come along recently though - The devotion and care these folks portray is seriously motivating ... I think the whole bedroom-programmer video game industry should come back!
@@suvetar What's cool about these new releases is that, because they are (generally) created by one person or maybe 2 or 3, and they're doing it out of love for the machine, they have the ability to take their time and fine tune it all they want before they release it. This is massively contrary to how it was in the later days of those old machines (but especially nowadays) where releases are under extreme pressure to be ready by a certain date OR ELSE. When programs were made for just a specific platform and not ported to other systems, they usually would start out as some pet project from a single programmer who poured him or her self into it and then brought it to a publisher. Later, other platforms wanted those games so they had to have programming teams set up to convert a game to their system. Of course the issue here is that a game made with the advantages and disadvantages (quirks, etc) of one system don't necessarily translate very well to other less powerful or just DIFFERENT systems and quality suffered. Still, I'd love to see some more 1-3 people-created games coming out for even new systems, but preferably those old ones...
Some tidbits about the first BASIC program: Line 40 defines "JJ" as 16384. This is the location of the ML MOVER routine, written by Jeff Jones, hence the JJ. By comparing two copies of a program assembled to different locations, it can create a new version to reside wherever you want. Line 110 skips all the LOADing of the modules, which was necessary during development, but not in the final product. I'm certain the modules were combined with the BASIC program in the final step, to create a one-file, one-load dealie using STAR LINKER. Another one of Jeff Jones' tools! Line 120's rough BLOAD command was used to load TOOLBOX 181 during this program's development. Lines 130-170 use the toolbox's version of BLOAD instead (since it's now in memory) which looks friendlier, but very likely follows the same rough method internally. Plus, many of these commands were based on TOOLBOX 105, which was created by... Jeff Jones! Your desired use of the MENU command should have been thought of. One more parameter or POKEable variable for "starting item" (plus 128 if that item is already highlighted - default value simply "1") would have worked beautifully here, plus removing any menu flicker whatsoever if STASHed at the right time. Oh well. Your hack works well. To disable the unwanted effect of the "home" key, add a POKE 37942,13. This replaces "home" with another "return" which (if pressed) was already dealt with earlier. I appreciate making the command summary available, but is it possible to add the "read me" text for the toolbox? It goes into depth about these commands, and removes a lot of the confusion. The summary is basically a reminder for what you should have already read, squeezed onto a single printed page.
Is this Lee?! Hello! I'm amazed by how often (and quickly) the original developers turn up when I make videos! Thanks for the great info. I did include both the "T.TOOLBOX 181" and "T.SUMMARY 181" files on the .d64 I linked in the description, along with the main "TOOLBOX 181" file, so the docs are there, but not as easily accessible as they should be. After I printed out the summary it was easy enough to take a photo of that with my phone and turn it into a pdf, but it wasn't so easy to do the same with the full multi-page read me. Do you have any suggestions on how to turn that into a pdf? I haven't figured out how to print to a file in an emulator yet. I'd happily link to it in the video description. Also, thanks for the history of the various utilities; I figured Jeff was involved somehow (and made sure to mention him in relation to LOADSTAR, anyway) but didn't realize that Toolbox 181 was so directly an extension of his work.
@@8_Bit Hello! Saw this video in my RU-vid suggestions this afternoon, and it definitely got my attention! I see Jeff Jones and Dave Moorman were here also! It's a strange feeling that all this was over 20 years ago, made by a younger someone who was once me. Yes, I see the docs were included in that image, but there's no need to try to share them. It seems this toolbox was the "mouseless" version of Mr. Mouse 2.1 (from issue #177) and users were to refer there to learn about most of the commands, many of which changed little or none. Only the differences were documented on issue #181. Basically, anyone who gets the LOADSTAR set will have access to everything anyway, including the Mr. Mouse toolboxes. Don't use V1 though. The mouse driver was made more responsive in V2, and even better in v3. I saw Jeff Jones as a kind of mentor, and it was fun brainstorming with him over the phone. Together we solved the greatest flaw with his STAR LINKER program, which I revised around 1999. Very proud of that.
This brings back memories! I used to LOVE Loadstar! Also loved Ahoy!, Compute's Gazette and Compute (in that order), still have several of those magazines. I have the last issue of Ahoy actually, which promised a really nice game in the next issue which never happened. :(
I thought I had the idea of doing a JRPG on the C64 completely as an original idea but after a project appeared on X16 I can see everyone is racing to do this.
I wonder if LMS used part of this routine to implement their menus in Super Snapshot V5? I don't remember there being more than three cascading menus on the same screen though.
Ah yes. Ultima IV. That game dates me for sure. I played it on three separate occasions. First time, far too young to actually beat it. Second time, two or three years later, finally beat it. Third time, I'd bought it in a semi-retro package deal including several Ultima games. It proved impossible to beat, because said package did not include the spell book, and that was needed to figure out how to make all the spells. Important because there are parts where you need to blink around the map to progress. So yeah, progressed from being unable to win, to winning, to being unable to win.
Thanks! Those are a reproduction of badges that some security guards at Commodore actually wore. My friend DLH gave it to me, I think he still has some for sale: www.lemon64.com/forum/viewtopic.php?t=65528
Looking forward to the RPG one. I've tried but could never get the logic right for making sure there were no inaccessible points on a randomly generated map.
Few days ago this tool has been released on CSDB: csdb.dk/release/index.php?id=196397 As soon as I've seen the demo I immediately remember this specific video. It looks easier than the LOADSTAR's Toolbox 181. Just an heads up. :-)
C64 is the best computer ever! It's amazing to see people are still using it. The assembler for 6502/6510 was and still is so fun. Did you know that the arm you see on all the videos on this channel, is literally just an arm controlled by another C64? 😜 And the voice is created with the SID-chip 😜.
Not sure JRPG's started this sort of pop-ontop menu thing. I remember selection screens on C64 game Pirates! as having the same pop-ontop menus. I had a similar menu that I wrote in QB45/PDS for MS-DOS. But it didn't store what was underneath the box as this does. Good stuff...
I think I understand the screen stash. Would it be smaller and simpler to just push the area of the screen under where the menu will be, or does that create more complicated problems?
Stash and Restore always affect the entire visible screen, requiring 8 pages per Stash. Cut and Paste, on the other hand (from Mr. Mouse 3.0 on issue 205), affects only a specified area, using only 2 bytes per screen cell. However, that command needs 5 parameters instead of just one! It would not have caused a problem here. But, the most elegant thing about Stash and Restore is you can Stash, open Menu upon Menu several layers deep, and get rid of it all with a single Restore. "Stashing" after each menu is only needed here since each menu is closed (erased) individually.
@@MorreskiBear Thank you. I figured an escape out of all menus would be an issue with cut and paste, so it would be limited to menu systems that backed their way out.
@@davedavenport8673 If you backed out of each one quickly enough, the effect is passable. Looks like that's how Final Fantasy on the NES did its battle menus!
MorreskiBear mostly answered your question, but in case further clarification helps: It would be smaller (in terms of memory use for the stashed screen data) but would take more code and data to support these "sub-screen-stashes" or whatever we'll call them. This Toolbox 181 doesn't have support for those smaller area stashes but as MorreskiBear points out, Mr. Mouse 3.0 does support that with its cut & paste features.
Nearest thing I can thing of to a JRPG on the C64 was Times of Lore? Real-time, top-down - can't remember how the combat worked though - pretty sure that wasn't JPRG like.
Yeah, the combat in Times of Lore is more action-RPG style, but otherwise is somewhat JRPG-ish. Andrew Fisher left a comment: "For those asking about JRPGs - Penultimate Fantasy is a mini JRPG on the C64, while Wonderland is more of a NES Legend of Zelda type game."
Nice review of the toolbox - Thank you! Quick question: On the Toolbox Summary printout - How did you get highlighted entries? The original doesn't seem to have the highlights.
Do the menu "windows" stretch to the length of the text? In your example, the menu "Main" (Item/Magic/Equip/Status/Save), if we add an longer option that is for example "Investigate", will the width of the window increase? I downloaded your code to study about this. I think it is very interesting and can be done something similar in other systems. Thank you!
The menu size can range from anywhere from a 1x1 cell to using the entire screen. This size needs to be predetermined. It has no idea what may lie below it (or what you might consider important) and simply reverses and colors segments to simulate a menu bar. Usually you would know what may be in your menu, and plan the size to reasonably accommodate the widest item.
@@merman1974 Thank you, I've tried two of these already, got to see them all. Found Fallen is fresh on CSDB. My idea of a good roguelike would be something like Sil. Though technically it is an Angband variant, it has very tight gameplay and rules that might somehow fit into the 64, definitely with some kind of RAM expansion.
0:20 How could there be more than one "Ultima"? It's a contradiction in terms! 9:00 I used the PEEK(186) trick when porting some VIC-20 programs to use disk drives. It's not so much the "current" drive as a unintended junk left behind from the most recent device access that happens to be useful. 10:10 If you were to just use a LOAD command, BASIC would get screwy about its memory management. 12:30 In principle, this could be stashed into only 1.5K of RAM with a little bit-shifting. 14:30 I guess it crashes demanding Meow Mix if S% isn't 1, 2, or 3. 15:15 I guess the Lattice routine automatically staggers the output by one character on each row. 24:37 They could have a toolkit routine for computed GOTOs. I recall COMPUTE! having such an article. 26:48 I always find it jarring to see PRINT"💟" without a semicolon. 28:40 So ML+21 is hard-wired to return its value in a specific variable. 34:16 I always litter my code with macro-activated debugging statements. 35:00 Wouldn't it be better structuring to do an ON GOSUB / RETURN than have every handler end with GOTO 700? 38:50 Could save a byte on every entry if the 6502 had a JSR (indirect) to go with its JMP (indirect). (Though not with JMP tables meant to be called from BASIC.) 39:00 Odd that you didn't mention the Kernal $FFxx JMP table as an example. 41:03 You could also change $9898 to LDA zp and manage a zero-page location. 42:47 Modern processors are more efficient when programmed in this way, with something of the form of LDA #1 : LDA.CC (s%), where the second statement has a built-in condition like Carry Clear, since branch instructions can be expensive to execute. 45:21 I think you wore out your "vinyl" player! 46:05 Geez, I've been demoted. Guess I'd better jump up a tier!
Interesting re: PEEK(186). The PRG and Mapping both make the "current device" claim, but I haven't looked at what the KERNAL is actually doing there to know any better. I do remember reading about a computed GOTO somewhere before; that would be a nice addition. It'd be fun to bring together a full framework optimized for making RPGs in C64 BASIC, with a full suite of ML subroutines. I'm always amazed when I remember that Pirates! and some other C64 classics used BASIC at their core. re: using ON GOSUB, yes, I should have mentioned I originally did that but it became really ugly when I tried to jump back a level in the menu after equipping an item (see the routine at line 1600). So I sacrificed the ability to RETURN, but was able to solve my problem by ending the routines with a GOTO 650 instead of a GOTO 700. Compromise? Thank you very much for jumping up a tier. Patreon provides me with a spreadsheet of backers qualifying for the credits perk, but I've never figured out how it is sorted, and for whatever reason, I never sort it myself, so it's just in Patreon order. Next time I download the spreadsheet, hopefully they will bump you up! Or maybe I'll have to start remembering to sort the spreadsheet myself.
@Dr. M. H.: I'm talking about the coding I do for work. I put a debugging statement after most of the important calculations so I can see during initial debugging and at all times in the future if the computation is proceeding how it's expected to. If the statement is activated by a macro or an optimized-out 'false' condition, then it doesn't take any code space or execution time (in a compiled executable), and then you just need to make the right tweak to activate one of them, all of them, or various levels of these debugging statements whenever you need to trace the execution again. It's less practical to do this in C64 BASIC since REM statements take code space and execution time, and there's no global way to activate or deactivate them.
I would have loved a magazine on disk when I was a teenager. :D I was all about doing things digitally rather than on paper. I was in my adult life too, to the point where I've hardly ever had a working printer. I like the attempts at visual structure in the source, I think they work pretty well. I can't use it though; I just learned Atari BASIC doesn't allow colons at the beginning of lines. Not that I write any Atari BASIC, although today I wrote 10PRINT. I really hate function calls with a lot of parameters, they give me a headache, but I couldn't tell you for sure what would be better. For graphics coordinates, pairs and quads (pairs of pairs) can help. Oh I'm curious, does Toolbox 181 actually draw the text in graphics mode? Or does the C64 support text over graphics or a split screen? I was wondering how to do it on an Atari. You'd either have to draw the text or use the display list feature to split the screen. (Or use the native split screen if 4 lines is enough.) Looking for where the program interacts with the user is a good tip for understanding code unless the program gives you the runaround. :) I had that trouble with some rather clever programs. In fact, they were menu-driven, and just like we're seeing here, menus need rather a lot of code. Atari programs using the screen editor might be trouble too, because the way to do that is to fill in a previously-opened IOCB for a read operation and jump to the Central IO entry point. I guess the way to do it would be to memorize the address range of the IOCBs, (there's only 6,) and look for a write of the correct command byte within that range. Or you could look for "E:", find the open call, and get the exact IOCB address from it, but if the code is called from BASIC on an XL or XE machine it will expect an IOCB to already be open. I guess that would be #0 though... IDK. I like Atari's little OS, but it would make this complicated. :)
Just out of curiosity, how hard is it to use this toolkit from ML rather than BASIC? I don't remember how that format of SYS translates (I know that a plain SYS is just a JMP/JSR, but no clue about the version with parameters.)
The toolbox was written so most commands were accessible from either BASIC or ML. The way to send those parameters differs of course (Robin's theoretical video explaining how BASIC did it would be very informative) but what is expected and how it gets them differs by command. The original documentation (not the command summary) refers users to an earlier Loadstar issue where every command (and expected parameters) was explained in length. When you call the ML version of Menu (JSR ML+114) for example, it expects the X and Y registers already point to the parameters in this order: MinX, MaxX, MinY, MaxY, Unhilight Color, Hilight Color, hotkey string ascii codes (if any), followed by a zero byte terminator. And since you called the routine from ML, it returns the selection in the A register instead of the integer S%. So, basically, it can be as easy as LDX #mymenu, JSR ML+114 in your code.
I thought Ultima 5 was okay but it felt a little too fiddly to me, with all the objects that could be interacted with but didn't really matter. I appreciated that Ultima IV was more streamlined.
@8-Bit Show And Tell +8-Bit Show And Tell 9:50 how exaclty does that SYS kernal abuse work? Also that SYS 65493 - does that avoid the Basic problem where a load from within a Basic program restarts the Basic program again (as if RUN had been typed)?
And yes, when using that SYS, the program doesn't start over again. Even though that can be an annoyance, it's actually by design as it allows one BASIC program to load another and continue on as if it's a huge single program. It was called "chaining" back in the day. And it's actually not as if the program has been RUN again, as no CLR happens, and variables are preserved for the sake of continuity within the chained programs. Sorry for all the "actually..."s :)
A silly way to cause a syntax error. If s% does not equal 1, 2, or 3 in line 430 (the only expected possibilities) then the program falls to line 440 and causes an error, and then it's time to investigate. A STOP command would have worked.
It's probably an obvious answer, but basically (lol) BASIC V2 doesn't support Hexadecimal arguments for Peek/Poke - I think it's because of how it stores the values along with the Tokenised representation of the BASIC program in memory! @UC3gRBswFkuteshdwMZAQafQ This would be a fascinating investigation video!
Hi, it's available to everyone, link is in the video description. If you tried that and it wasn't working, try it again now. I just changed the url from http to https as it seems RU-vid munges the links somehow.
I sent $15 to the email address for the loadstar compleat a couple days ago but I haven't heard anything back. Do you know if this is still being sold?
Hi, I'd suggest emailing Fender at that same address and give him another day or two to respond. Let me know if you still don't hear from him, and I'll try to contact him.
On 41:30 you do POKE 39065,3 in order to change LDA #$01 to LDA #$03. But when you say "let's try it out", I think you don't actually try that. Instead you try out the version with the dynamic POKE hack. At first I thought you were just a big liar but then it turned out you just skipped ahead a bit in time :-)
Yeah, I didn't actually do the POKE there in the machine language monitor (in fact, it's not even capable of parsing the POKE command); I just typed it in to illustrate what I was saying. But I do use that POKE with a variable in the BASIC program afterwards. Sorry it wasn't clear enough.
Programmers put crazy stuff in their code sometimes to remind them of tasks they need to do outside of programming. I was working with a guy and he put in his notes REM Remember to call the boss for an update he's such an an Idiot! Problem was I printed his code for a meeting there it was in black and white!
