I was hoping to help simplify the use of an REU. I had to do the hard work of figuring out how to use them, so here I am simplifying it for those who want to give them a try. I expect their use to increase over time, but they can be confusing for those who read a lot of the information available on the internet.
I love watching Robin's channel! I think a lot of people are waking up to how powerful these add-ons are. I plan to do another video on the REU, but right now my focus is with Vision BASIC for now.
They have no use if a cartridge is not plugged into the C64 (as far as I know). You can access the RAM underneath these locations if you turn off the BASIC and Kernal ROMS. But you cannot expect to use these registers as RAM from BASIC.
Paid $300 for a 1764 3 years ago- well before the RAD device was known/avail, as modern equiv carts were out of stock everywhere! So glad more choice are avail to others now.
Yes, and I would certainly love to see them used even more! I paid about $100 for my REU (on eBay). I'm sure that they cost much more now due to demand.
What a wonderful video. Using an REU from BASIC on a 64 is not something anyone does, like, ever. And it's not only done here, but in a variety of useful ways. Great stuff. P.S. In your size detection, have you considered using a binary search?, e.g..: 100 tp=0:bt=255 110 mi=int((tp+bt)/2) 120 if *bank **#mi** exists* then tp=mi:goto140 130 bt=mi-1 140 ifbt>tp+1then110 150 if *bank **#bt** exists* then print "number of banks=";bt:stop 160 print"number of banks=";tp:stop Ignore if you are already doing this -- I just got the impression you were doing some sort of linear iteration...
I'll have to look at this after I get some sleep! My brain isn't up to task at the moment. :) If I were to take a quick guess, I guess you're talking about doubling the bank number? I thought about doing that at least. I'll probably only revisit the REU topic one more time, so if I can speed up the routine before then, I'll update my routine for sure!
I may or may not have seen this formula before. Interesting regardless! I tried to follow it a little bit (on paper) but will have to further test it. The only inaccuracy is that the number of banks should be bt+1 in line 150 (if bt starts out at 255). I'm only saying this in the literal sense of how many banks would exist. I know that the top bank would still be numbered "255", but the count should be 256 banks. My formula is a little linear, but was considerably faster than the routine I copied from. I also have a ML routine I use, but it's possibly less "efficient" (but quick enough in the area of "detection" not to really matter). I guess it's theoretically possible for an REU to have 1.5 MB (for example), which could cause issues with quick detection. But I don't know how the hardware would respond to having RAM that isn't a power of two.
The binary search algorithm, in english, is something like: I'm looking for X, and I know it can't be lower than TP or higher than BT, so I'll check the point between them. Is that middle point (e.g.) higher than X? Then that point becomes the new BT, otherwise it is the new TP, and we rinse and repeat until it's narrowed down. It doesn't just cut your checks in half -- it repeated halves your range each time (log(n)). It is typically used to search for words in a dictionary, but works here too, and is a wonderful tool in any programmers arsenal.
@@bozimmerman I'm familiar with the concept. I just have to see if it works with an REU. I used the concept once in a program of mine and it did speed up the searching for me for sure. I remember it being talked about in a computer class I took back when I was in high school. Most REU detection routines seem to check all the banks. I'm not sure why that is. In machine language it's not really an issue because the detection is fast enough not to notice any delay. A detection only needs to be done once in a program. With BASIC, faster detection is always a welcome thing. I will try your idea out before I do my next REU video!
BASIC V2 is extremely slow, but there are awesome compilers for C64. Try native old-school Boss Basic, it's been around since 1988 (!), and see for yourself. Produces very efficient, optimized machine code, if you learn well its various options.
Did you comment in Facebook too? :) I certainly think this is a great recommendation and I think any BASIC programmer should consider this as another tool in their arsenal - the use of any compiler to help eke out more speed. Whatever helps the programmer accomplish their goals (as opposed to the usual disappointment in the speed of BASIC by itself)! I figure if I help others get better speed out of regular BASIC, then when they compile their code, it will be even better.
@@visionbasic , yap! Advocating compilers for C64. They are feature, of course, but it is wise to know something about the subject and use some tips while coding in V2 - with some discipline, later optional compilation might get VERY efficient and produce very fast machine code. C64 deserves goot software in 21st century, and good old BASIC V2 can provide it. If we help him a little! This game is 99% done in V2 and compiled with BOSS. Go figure. ua-cam.com/video/lR5dvXYcPPQ/v-deo.html
@@cybermodo So even the raster interrupts are handled in BASIC too?!?! When I looked at how the sprites would have to be combined to create the larger sprites with tons of colors, it seems that the sprites would have to be moved down half way down the full shape in order to work properly -- and that would require an interrupt (I would think).
It's extremely slow compared to assembly or most compiled languages, sure, but BASIC V2 is actually faster than the BASICs on several other computers from the era, such as Atari's, Sinclair's, and TI's. It's pretty much the same speed as Apple's and most other competitors. The only BASIC that really stands out as much faster is the BBC's and that's because the CPU/RAM are clocked at double the speed. Maybe that's all you meant, but it's a common myth that C64 BASIC is slower than other BASICs, but that doesn't stand up to any scrutiny as many different benchmarks available online show.
@@8_Bit , sure, I just made comparison to machine code. V2 is fine scripting / cmd language, and there is always possibility of comfortable hybrid approach, mixing mcode routines with BASIC. However, some mechanisms of V2 under the hood seem really wasteful. Like, doing integer arithmetic still converts everything to very slow floating point, and then converts back to integer. Or string handling with wasteful memory use, and very clunky garbage collection. But that's fine - again, accepting V2 as scripting/cmd interface, and use various other languages loaded from tape/disk. I believe C64 was built with HUGE amount of RAM (back in 1982) having in mind booting into something more powerful, so BASIC V2 was left as it is just to be around for interfacing with a user (and it does that really fine). It's good V2 has no graphics/sound and advanced functions, because back in 1982 nothing would do proper justice to its cool chipset. Commodore left that for users to choose. Loading some advanced expansion or new language still left decent amount of memory for user's code - by the norms of the early 80's! Any opinion on Ocean's Laser BASIC? Around 17K free, but also some 25K also free in various parts of the address space... and some 250 commands / functions... and compiler available as well! Go figure. PS - great show you keep doing on YT, mr. 8-bit, I like it a lot. Please continue with your fine work!
There is a guy making a cartridge that functions just like an REU (for maybe $50 or $60), but I don't know if anyone will ever be able to recreate the original hardware.
@@davidpotesta There was someone who was trying to make a cartridge that emulates an REU and it was supposed to retail for perhaps $50 or $60, but he hasn't posted anything about the project for awhile (that I'm aware of). Perhaps the chip shortage affected his efforts? Regardless, I'm sure that others are trying to create similar products because of the demand. If the RAD github product reproduces the functioning of an REU sufficiently, it should work with Vision BASIC. I have not had a chance to test one of these devices. But a person should be able to run a normal REU test on the device to see if it does function identically to an REU. If the RAD product works with games requiring an REU, I'm not sure why it wouldn't work with Vision BASIC.
I've never actually played the game (if you're talking about "Rescue on Fractalus"). I've seen tons of videos about it though. Pretty cool-looking for its time.
@@visionbasic Yeah that's the one, I remember I was impressed with the gfx when it came out, fractals where all the rage back then, Benoit Mandelbrot came out with his fractal set in 1980, rescue on fractalus came out in -85 so I guess it was in the Zeitgeist by then. It's clever since you don't have to store a huge world as data, but you can generate it with maths instead.
Great video. Lots of knowledge packed here.
I was hoping to help simplify the use of an REU. I had to do the hard work of figuring out how to use them, so here I am simplifying it for those who want to give them a try. I expect their use to increase over time, but they can be confusing for those who read a lot of the information available on the internet.
Great video, very interesting. Have you seen the '8-Bit Show and Tell' channel here on UA-cam? He does a lot of commodore 64 basic and Reu work.
I love watching Robin's channel! I think a lot of people are waking up to how powerful these add-ons are. I plan to do another video on the REU, but right now my focus is with Vision BASIC for now.
Super awesome! Fun stuff!
Thanks so much! I'll do another REU video, but my next one is going to focus on Vision BASIC some more.
BASIC, and Osbourne BASIC books. I know they're not you. I am engaging.
🤘
I don't know how distant the relation is, LOL! But can't be too far, eh?
What are the 57090 and so on locations used for if there is no REU?
They have no use if a cartridge is not plugged into the C64 (as far as I know). You can access the RAM underneath these locations if you turn off the BASIC and Kernal ROMS. But you cannot expect to use these registers as RAM from BASIC.
Paid $300 for a 1764 3 years ago- well before the RAD device was known/avail, as modern equiv carts were out of stock everywhere! So glad more choice are avail to others now.
Yes, and I would certainly love to see them used even more! I paid about $100 for my REU (on eBay). I'm sure that they cost much more now due to demand.
What a wonderful video. Using an REU from BASIC on a 64 is not something anyone does, like, ever. And it's not only done here, but in a variety of useful ways. Great stuff.
P.S. In your size detection, have you considered using a binary search?, e.g..:
100 tp=0:bt=255
110 mi=int((tp+bt)/2)
120 if *bank **#mi** exists* then tp=mi:goto140
130 bt=mi-1
140 ifbt>tp+1then110
150 if *bank **#bt** exists* then print "number of banks=";bt:stop
160 print"number of banks=";tp:stop
Ignore if you are already doing this -- I just got the impression you were doing some sort of linear iteration...
I'll have to look at this after I get some sleep! My brain isn't up to task at the moment. :) If I were to take a quick guess, I guess you're talking about doubling the bank number? I thought about doing that at least. I'll probably only revisit the REU topic one more time, so if I can speed up the routine before then, I'll update my routine for sure!
I may or may not have seen this formula before. Interesting regardless! I tried to follow it a little bit (on paper) but will have to further test it. The only inaccuracy is that the number of banks should be bt+1 in line 150 (if bt starts out at 255). I'm only saying this in the literal sense of how many banks would exist. I know that the top bank would still be numbered "255", but the count should be 256 banks.
My formula is a little linear, but was considerably faster than the routine I copied from. I also have a ML routine I use, but it's possibly less "efficient" (but quick enough in the area of "detection" not to really matter). I guess it's theoretically possible for an REU to have 1.5 MB (for example), which could cause issues with quick detection. But I don't know how the hardware would respond to having RAM that isn't a power of two.
The binary search algorithm, in english, is something like: I'm looking for X, and I know it can't be lower than TP or higher than BT, so I'll check the point between them. Is that middle point (e.g.) higher than X? Then that point becomes the new BT, otherwise it is the new TP, and we rinse and repeat until it's narrowed down. It doesn't just cut your checks in half -- it repeated halves your range each time (log(n)). It is typically used to search for words in a dictionary, but works here too, and is a wonderful tool in any programmers arsenal.
@@bozimmerman I'm familiar with the concept. I just have to see if it works with an REU. I used the concept once in a program of mine and it did speed up the searching for me for sure. I remember it being talked about in a computer class I took back when I was in high school. Most REU detection routines seem to check all the banks. I'm not sure why that is. In machine language it's not really an issue because the detection is fast enough not to notice any delay. A detection only needs to be done once in a program. With BASIC, faster detection is always a welcome thing. I will try your idea out before I do my next REU video!
BASIC V2 is extremely slow, but there are awesome compilers for C64. Try native old-school Boss Basic, it's been around since 1988 (!), and see for yourself. Produces very efficient, optimized machine code, if you learn well its various options.
Did you comment in Facebook too? :) I certainly think this is a great recommendation and I think any BASIC programmer should consider this as another tool in their arsenal - the use of any compiler to help eke out more speed. Whatever helps the programmer accomplish their goals (as opposed to the usual disappointment in the speed of BASIC by itself)! I figure if I help others get better speed out of regular BASIC, then when they compile their code, it will be even better.
@@visionbasic , yap! Advocating compilers for C64. They are feature, of course, but it is wise to know something about the subject and use some tips while coding in V2 - with some discipline, later optional compilation might get VERY efficient and produce very fast machine code.
C64 deserves goot software in 21st century, and good old BASIC V2 can provide it. If we help him a little!
This game is 99% done in V2 and compiled with BOSS. Go figure.
ua-cam.com/video/lR5dvXYcPPQ/v-deo.html
@@cybermodo So even the raster interrupts are handled in BASIC too?!?! When I looked at how the sprites would have to be combined to create the larger sprites with tons of colors, it seems that the sprites would have to be moved down half way down the full shape in order to work properly -- and that would require an interrupt (I would think).
It's extremely slow compared to assembly or most compiled languages, sure, but BASIC V2 is actually faster than the BASICs on several other computers from the era, such as Atari's, Sinclair's, and TI's. It's pretty much the same speed as Apple's and most other competitors. The only BASIC that really stands out as much faster is the BBC's and that's because the CPU/RAM are clocked at double the speed. Maybe that's all you meant, but it's a common myth that C64 BASIC is slower than other BASICs, but that doesn't stand up to any scrutiny as many different benchmarks available online show.
@@8_Bit , sure, I just made comparison to machine code. V2 is fine scripting / cmd language, and there is always possibility of comfortable hybrid approach, mixing mcode routines with BASIC.
However, some mechanisms of V2 under the hood seem really wasteful. Like, doing integer arithmetic still converts everything to very slow floating point, and then converts back to integer. Or string handling with wasteful memory use, and very clunky garbage collection.
But that's fine - again, accepting V2 as scripting/cmd interface, and use various other languages loaded from tape/disk. I believe C64 was built with HUGE amount of RAM (back in 1982) having in mind booting into something more powerful, so BASIC V2 was left as it is just to be around for interfacing with a user (and it does that really fine).
It's good V2 has no graphics/sound and advanced functions, because back in 1982 nothing would do proper justice to its cool chipset. Commodore left that for users to choose. Loading some advanced expansion or new language still left decent amount of memory for user's code - by the norms of the early 80's!
Any opinion on Ocean's Laser BASIC? Around 17K free, but also some 25K also free in various parts of the address space... and some 250 commands / functions... and compiler available as well! Go figure.
PS - great show you keep doing on YT, mr. 8-bit, I like it a lot. Please continue with your fine work!
What are you pressing to make the program run faster?
Alt-W turns warp mode on and off for VICE.
Cool!
Thank you! :)
😯👍
now some one needs to make a legit REU
There is a guy making a cartridge that functions just like an REU (for maybe $50 or $60), but I don't know if anyone will ever be able to recreate the original hardware.
@@visionbasic Are you referring to the RAD github project that uses a Raspberry Pi? If so, do these replicas work with Vision BASIC?
@@davidpotesta There was someone who was trying to make a cartridge that emulates an REU and it was supposed to retail for perhaps $50 or $60, but he hasn't posted anything about the project for awhile (that I'm aware of). Perhaps the chip shortage affected his efforts? Regardless, I'm sure that others are trying to create similar products because of the demand.
If the RAD github product reproduces the functioning of an REU sufficiently, it should work with Vision BASIC. I have not had a chance to test one of these devices. But a person should be able to run a normal REU test on the device to see if it does function identically to an REU. If the RAD product works with games requiring an REU, I'm not sure why it wouldn't work with Vision BASIC.
Who here remembers return to fractalus? 😂
I've never actually played the game (if you're talking about "Rescue on Fractalus"). I've seen tons of videos about it though. Pretty cool-looking for its time.
@@visionbasic Yeah that's the one, I remember I was impressed with the gfx when it came out, fractals where all the rage back then, Benoit Mandelbrot came out with his fractal set in 1980, rescue on fractalus came out in -85 so I guess it was in the Zeitgeist by then. It's clever since you don't have to store a huge world as data, but you can generate it with maths instead.
my god this is some complicated shit not worth getting into
I recommend to change the char color.
The C64 colors seem to be an issue for some people. I can focus more on this for future videos.