Відео

Very cool vid, thx for sharing. Cool idea to cover this topic, however unpractical it is. It is still a cool reminder of the practically infinite possibilities capable of the c64.

I've seen program lists back in the 80's like this and always was triggered by the actual very short time where you can see the line is printed, then deleted and other characters are written over the same line. Sneaky, but still visible by the human eye. And of course when you notice it, you get kids like me studying it through my machine language monitor. #PowerCartridgeAllTheWay

Brings back old memories.

This bring back so many memories !

This feels like the kind of ingredients that viruses are made from.

This was the defacto way of doing machine code on the ZX81 and Spectrum but i think the clever trick for hiding the gibberish would only work on a Commodore... nice!

Isn't there a way to link machine language program with some sort of subroutine call? In the AIM-65, you set up a USR (user function) call to the program.

I know this is C64, but I always wondered how they got Machine code in to Rem Statements in ZX Spectrum Basic, and this pretty much explains it for me, First line, Rem "<random ascii to the length of the Machine Code" Then use some sort of Memory Editor to edit out the Ascii as machine code, then once edited, the Rem Statement contained the Ascii representation of the code. Then in ZX Basic (I do not know about 64 Basic), use a specific Poke in to the OS, that turned the Line 10, in to Line Zero, aka : 0 Rem "<Machine Code>", Poke 23756,0 to turn the first basic line to "0", then also they would use 16514,118 and POKE 16515,118 and the listing would not be visible on screen. ZX Basic would be Blank.

@5:10 you didn't need to re-do all that, but I suspect you know that. Just enter the del key string.. Well I never had to hide anything in REM statements, I always had a Super Snapshot V3 to do my assembly in.

Wish I did keep the 64 I did have interesting stuff

Have you considered placing a shift-L right after the line number 10 REM?

I'm an old guy too, I don't know much of your previous work here, but I have been writing some old Basic too, (and ASM since) your video is ... wicked, you made me laugh for the hiding idea. Peace & Prosper. ❤🖖

I don't see the point of doing this. Okay, if it is important to hide the machine code from prying eyes, then maybe, but considering that it is limited to 80 bytes per REM statement, and that anyone sufficient interested would know how to enter the debugger and just look, then how much value and secret can those 80 bytes be? On top of that, with all those DELETE characters added in, you are using 160 bytes of memory to hide 80 bytes. As an intellectual exercise, sure. It's neat, and putting the instructions for calling the code into the REM statement, that is nifty too. But at the end of the day, I would just put the hex-codes into DATA statements and have a little FOR/READ loop POKE the bytes into place. It is easy to edit, no limitations on the size of the code, no problems with adding lines to the BASIC program itself, etc.

I read about another method which was almost the same, except that it was done using a string literal. The advantage of using a string literal is that you can use the VARPTR function to find where the string is stored without having to manually search for it. Once you have POKEd the entire machine language routine into the string, you can then delete the code which loads the machine language routine into the string and save the program without those lines. But of course the same problem of having the machine code display as control characters applies, unless you save the program before the machine code has been POKEd into place and leave those instructions intact. While it's possible to force the string to be copied out of the literal and into string space, that rather goes against much of the reason for putting the machine code into a string literal in the first place. However what it still does is to remove the requirement to create "reserved" memory before entering or loading the program.

Thanks for the teaching video.

You can also do special PETSCII in REM statements so when listing you can spice up the look. Or just a shift+L after a REM will stop the listing. I'm sure somebody already mentioned it.

Evil, but brilliant!

At 5:54 - 5:55 which apparently is the new number of the beast the ultimate BLASPHEMY has been completed. The C=64 does has a RETURN key damnit!!! REPENT AND THOU SHALL BE SAVED!!!

I used to do this on the ZX Spectrum. It was amazingly easy to get just one figure wrong, and crash the computer... or occasionally give a weird cool effect.

I recently did something similar! I built a homebrew computer based on the MC68701. I managed to get TinyBASIC for the MC6800 running on it. One program: tic-tac-toe, uses a scratchpad of nine bytes right where my registers are located (or, maybe it was my stack. The takeaway: it was in my way.) Since TinyBASIC has a register that indicates the start of the BASIC program, I used that with an offset to place the scratchpad in a REM statement at the beginning of the program.

Very cool stuff my friend. i built my first cnc machine with the vic20. it didnt work very well and i ended up moving to the ibm clone. This trick would have solved problems i couldnt figure out at the time... subbed,,,

Stuxnet!

Many decades ago (back in the day, early 1980s), I was able to hide BASIC in BASIC. I did this on the TRS-80 Color Computer, but the same approach would likely work on any early computer with MS-BASIC. The approach is to pack the program with an obscure character, such as "\". Then run a routine (e.g. up in line 1000) to find (PEEK) and replace (POKE) the character with backspace (08). Then delete the extra routine. The hidden backspaces overwrite what is displayed with LIST, leaving only what you wish to appear in the REM part of the line. End result is (for example): LIST 10 PRINT "NO NO NO" RUN YES YES YES Explanation = 10 PRINT "YES YES YES"; REM \\\\\\\\\\\\\\\\\\\"NO NO NO" One can make LIST appear to RUN and RUN appear to LIST. Anything is possible...

"Super Mon... who can change the code of Basic programs... bend pins with his bare hands, and who disguised as a simple assembler for a great american computer company... Compiles the never ending stream of apps, drivers via the programmers way!

Oldies but Goldies !

Would it be possible to hide the binary code *in between* the basic lines? I mean, create a block of normal basic lines (with REM probably) followed by some normal basic program and then cut the first REM line short with zero and pointer to the first actual program line, which would give us space hidden in between the basic lines, which we could fill with anything. Is that possible or is there something, that would prevent it from working? Like some automatic cleanup of space in between the lines or something.

As a kid, I remember seeing this on some games I tried to decode. (Before I knew what machine language was) I thought it was purely a copy protection scheme.

🔹One other limitation: You can not add or delete any basic line *before* the REM statement. When the BASIC editor moves the REM to make room for the new line, it replaces any reverse character (any number in the ML above 128) with it's non-reversed version (basically subtracting 128 from the number). You actually can add or delete a line before the REM statement, but you must re-enter the ML in the monitor and understand that the start address of the ML and any specific target address within the code will change. 🔹If you absolutely need to LDX #$00 (or similar) use LDX #$01; DEX or use LDX #$FF; INX. Either of these adds an extra byte to the ML code. Also keep in mind the first sets the Zero flag and the second sets the Carry flag which may or may not be important to the rest of the code. 🔹You can not STA $0400 (top left screen character) or any other memory page boundary address because of the low byte "00". You can get around it by using Indirect Indexed Y addressing and figure out a way to get a "0" in the low byte of the pointer address. LDX #$01 DEX STX $0334 (820) LDX #$04 STX $0335 (821) ... ... STA ($0334),y (the pointer address held at 820/821 is 1024 ($0400) or the top left character position of the screen)

Could you not use multiple rem statements ?

Fascinating. I never thought about it. Great example. With hiding the ugly REM statement at 7:06, can't you insert a $0, and the address to the next line as part of the REM statement, and move the sys address a few bytes ahead in memory. It might also save you from all the delete characters in your PLOT AT example. My guess is the EOL is only actually used for listing/running, but not for saving.

I remember similar on the zx81, the basic program would be a rem statement and a loader, run it and type the machine code in hex into the loader which would place it in the rem statement. Some programs even used the 300 bytes of the tape buffer. One mistake and the whole thing would crash and be lost.

So what happens if one of the machine code bytes is D6 the " character?

Very cool!!

I remember back in the day being completely confused by a BASIC program that only consisted of "10 SYS 49152" or something similar. Years later I discovered what was going on here. Another clever trick I remember from the old C64 days was something along the lines of this: 10 IF A=0 THEN A=1: LOAD "PART 1",8,1 20 IF A=1 THEN A=2: LOAD "PART 2",8,1 30 IF A=2 THEN A=3: LOAD "PART 3",8,1 and so on for as many parts as you needed. Essentially, when the first program exited, BASIC would always start reading from the beginning of the BASIC program, but the value of variables would be retained, so checking for and then changing the value of A would allow each section to be loaded in turn. Pretty clever!

2:30 "When the program is run, we get that ugly flashing border effect." 😆

Cool technique, thanks! For the first example, you can also skip using a monitor and just copy the bytes over directly... 10 fori=0to16:reada:poke828+i,a:next 20 sys828 30 data173,32,208,72,238,32,208,32,228 40 data255,240,248,104,141,32,208,96 run new 10 rem"xxxxxxxxxxxxxxxxx" 20 sys2055 fori=0to16:poke2055+i,peek(828+i):next run

You go a subscriber, a very picky one. I already know the REM trick, but I never used 🆃 to tidy it up.

this is how it was done on the Spectrum as well: first BASIC line was a REM with Z80 assembly op codes. iirc you could also set the color to white-on-white with CHR$(). second line executes machine code using RANDOMIZE USR + known address of begin of basic =]

Ah yes, I did this back in 10'th grade (1982?) on a Swedish manufactured machine named ABC-80. A Z80 machine with a built-in BASIC interpreter. I remember spending most of my non-class time in school coding away at a Space Invader game. Some parts of it was in basic and some in Z80-assembly manually POKEd into long REM-statements to speed up the game to something playable. There was no assembler on the machines so I had to assemble by hand and make sure all memory references and jumps was adapted to where the REM was in memory. And of course no debugger. So either it ran or it did't and I had to figure it out "in the blind". It took quite a while but in the end I got it running.

WHOA! This is so cool! 👍👍Earned a sub. MY C64 is only an emulator, But I hope to get some real gear! I was a C64 user in the 80's and this stuff (to me is STILL more fun to mess with the "innards" than the modern stuff!)

curious about nested multiline comments enabling similar hidden code in c

Oooo, brings back my C64/128 days. My brain is stretched.

One trick is to put the ML in it last and then save it. Once you edit the basic program the work is lost. Not fun to edit but you can make it work

Won't there be a problem as soon as the hex 22 (so the quote character) is used?

❤

The character set can be turned to lowercase by PRINTing CHR$(14) and to uppercase with CHR$(142).

Fascinating. I have seen all kinds of REM tricks over the years but I have never seen this one. Excellent trick, Thanks for sharing!

Sneaky. I love it!

It's a shame that there was never a SIMONS BASIC compiler available from the author of SIMONS BASIC, David Simons.* I had SB and played with it relentlessly as a teenager. * This points out a revelation I had years ago, that it is not named after a guy named Simon as a first name, but after a guy whose LAST name is Simons, therefore the apostrophe is not to be used.

I had "Simons Basic" and felt very alone. It is such a pity that C64 basic was so lame, having no dedicated commands for graphics (e.g. SETDOT and GETDOT), sprites or sound. Commodore should have offered Simons Basic as a free option with the Disk Drive and a cheap upgrade. That way, much more would actually program instead of just waste their time gaming.