Відео

This looks like a very useful tool. Is there a place where one can purchase the full version for Windows?

Nice comprison! I am interested, if you could share th code here (as a text)? I would like to make a try with Commodore Plus/4. It has some compilers, but none of them make the gfx command faster, but otherwise the (on average) 1.23MHz CPU is quite capable. It would be interesting ,if the natibve and the Austrospeed complied version how perform compare to these. Many thanks in advance!

Do you have any videos or source code regarding your interrupt timing routines?

nice little trick

Not sure if you saw this already, but there is a program called REM Highlighter in the January 1986 edition of Compute's Gazette Magazine (Issue 31; page 108).

I had a Super Expander cartridge my impression at that time was that the Abacus compiler just did the redirect into the ROM for those additional Basic commands but didn't optimize beyond that.

It would be interesting to know why exactly hitting return corrupts the code, and why this particular corruption.

My 1st computer was a Timex Sinclair.... my 2nd was a Commodore 64. Please keep up the awesomeness.

Nice test. I see you didn't try fast mode on the 128, it will not support graphics in fast mode, but runs at about 2mhz.

Do 100 pins create so much chaos that it's basically impossible to get fewer than 95 of them?

All of the line-drawing routines are so slow that you can actually see each line being drawn in real time. All the different graphical systems must be using BASIC-ROM floating-point calculations instead of integer methods. The C128 version would run more than twice as fast in FAST mode, though you wouldn't be able to see the progress until it's done.

How fast would the Qsort run for the modern Vision Basic compiler?

That was the most interesting 6 minute video I have ever seen. Well done!

My guess is that you're really benchmarking how fast each system draws a line. I'll bet most the time is spent in the line-drawing function.

Cool. Did not know you can do that! I'm assuming the compiled program still needs the SuperExpander cartidge?

not trying to be pedantic but isnt it 'machine code' when its down at an executable byte/word instruction level, and anything that needs compilation or interpretation is 'language'? edit: I googled, I'm not keeping up with the times....... Machine code, also known as machine language, is the elemental language of computers.

Commodore manual: "Screen memory is not an appropriate place to store machine language programs." Me: "Hold my beer." SYS 1024

Can you do a review of Vision BASIC for C64? Most of the videos about it seems to come from the developer's account which hardly is unbiased. I am considering getting it, just need to see some benchmarks to see if it's really much faster than regular BASIC to make c64 games with.

That LDA from the line number was pretty cool. Neat stuff

0:52 You could also LDX #1 : DEX to get a $00. 2:00 Hidden dependencies can be dangerous. Technically, it's not the '0' digit in the "10" but the line number being ≤ 255, and the $00 is in the most-significant byte. 2:11 $800 seems more reliable, since BASIC programs won't actually RUN if location $800 isn't a $00. Though, I guess the low byte of the address is a problem.

Thanks for the tip on retrieving a zero byte indirectly. 2:08 "As long as the BASIC line number ends in a zero..." I think as long as the line number is less than 256 it should work because address $804 is the high byte of the line number.

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 ?