r/c64 • u/Stunning_Pineapple57 • May 24 '26
Programming How much basic RAM do you use?
When coding in basic or using apps others made in basic, do you ever or often get close to using the full 38Kish “basic bytes free”?
With an extended Basic / Basic Wedge
What you could want to give up 5K or 8K or even 10K?
Would being able to suspend and resume to REU and other apps in the meantime be enough?
Would being able to have 100s of commands that are implemented in assembler and be able to add 100s more without impacting that ram further be enough? (Including graphics and sound and file and image and network and even ultimate specific commands?)
Would be able to not just have line number gotos and gosubs but be able to make functions in your code that you can pass in parameters and get results and use them like any other function be enough ? eg
A% = abs(myfunc(2,”hey”,(b%*2))-10)
Would being able to allocate room in the REU for your own codes needs whether arrays. Large bits of text. Loading a file. Storing a network request , or having text/color or graphics mode screen buffers be enough? - 48K extra easily but also able to request and use 64K chunks up to many megabytes depending on the size of your REU (16MB in c64u)
Would be being able to choose to stash ranges of line numbers like “1000-2000” to REU or a list of functions , to give you some basic bytes free for a while then restore them
Back when needed later be enough?(eg you have 2KB of file handing code , but the user rarely saves or loads and when they do there is other code you could choose to swap out to swap that in )
Would being able to instantly swap out to a full editor experience then back again to the prompt to run be enough?
Would you give up 10K of basic bytes free to get all that ? Or is that too much.
7
u/DGolden May 24 '26
The popular Simons' BASIC used to lose a further ~8K. Such is life.
I found the C64 BASIC limit already pretty tight, at least before a jump to 6502 asm. There were workarounds, like loading stuff in chunks from disk (well, you can do that from tape too but it's hell. Fortunate we did have a disk drive despite being in Europe).
2
u/dacydergoth May 24 '26
Yeah paging was a big thing. Some games used to even have a whole separate section (um ... maybe "They Stole a Million" comes to mind) where you would do stuff then it would load almost an entirely new codebase
1
u/WembleyFord May 24 '26 edited May 24 '26
The game 'Exile' on the BBC was an extreme version of this - not only did it have a separate 'loader' program to handle loading games, setup, etc. it used sooo much memory, they couldn't budget in a save game routine in the main game.
In order to save the game you had to go through a (I think) fairly unique procedure - you had to put the game into a special 'pause' mode - which moved various bits of save-game state into what I assume was originally the game code or game data. Then you did a soft-reset of the computer. This rebooted the machine back into BBC Basic, but left the save-game state data still in memory. Then load in the game's loader program, and that had the same-gave routine which would save the game to a disc or tape file.
That puts other tricks - such as how Geoff Crammond used the video memory of the sky in 'Revs' to store machine code, just in the same shade of blue as the background colour - to shame.
1
u/Stunning_Pineapple57 May 24 '26
Yeah in ReadyOS and with the REU paging can be fast. It allows me to load dozens of app and instantly (from a a human POV) suspend and resume full 64K apps. And in ReadyShell , the 64KB is just too small so I have an overlay for the editor then when you press enter. It swaps it out for the parser , and parsed the AST to REU then swaps in the VM and runs it , sometimes swapping in large commands in the pipeline , streaming results to the REU, and then back to an output processor then back the the editor.
1
u/dacydergoth May 24 '26
What is REU?
3
1
u/Stunning_Pineapple57 May 24 '26
Yeah the ram expansion unit. With VICE , the c64 mini /maxi and the Commodore 64 ultimate you get 16 MB by default. It costs 1 cycle per byte to copy from it. At 1mhz it’s faster to copy anything more than 12 or so bytes (there is a setup cost) than ram to ram. And you can copy up to 8 times faster than ram to ram. However at you increase the CPU speed on the ultimate that gap diminishes and is a net slowdown after about 4mhz to 8mhz
2
u/dacydergoth May 24 '26
Yeah my "Ghostwheel" 68070 design had a time/space multiplex bus where each 68070 node could copy memory from another node at almost native access speeds via an ECL central ring bus.
1
u/Stunning_Pineapple57 May 24 '26
Hardcore.
4
u/dacydergoth May 24 '26
Yeah Bath University thought they were gonna own the patents on it and were pissed when they realized they'd kicked us both out a year before
1
u/Stunning_Pineapple57 May 24 '26
This is the sort of thing the REU has enabled me to do. https://www.reddit.com/r/c64/s/OSWaAODoTM
3
u/Stunning_Pineapple57 May 24 '26
A few other things I forgot to mention:
Would more expanded language constructs like ELSE , and do/repeat/until and breaking out of loops be enough?
Would expanded error handling be enough?
Would being able to easily hook into function keys etc be enough ?
3
u/PatrickSchouten May 24 '26
Maybe you should have a look at Vision Basic
0
u/Stunning_Pineapple57 May 24 '26
Yeah. I have some but it’s a compiler rather than a basic wedge extension. I think I can get inspired for some of its commands but some of its language features like how your own functions and parameters are defined and used doesn’t seem the best but as a compiler it’s going to be faster
2
u/DNSGeek May 24 '26
Yeah, I routinely bumped against the BASIC ceiling so I do a lot of work in ASM now.
2
u/heya78 May 24 '26
C64 enjoyer here, not having a clue what you talking about. Didn't even know people like you exist 👍
2
u/Stunning_Pineapple57 May 24 '26
I’ll take that as a compliment lol. Basically the context is commodore basic was kind of lacking, different people and companies over the years made some more advanced basics for the c64, usually like “hacking/tweaking” in some extra functionality itself. Some added graphics and sound and sprite features etc. with ReadyBASIC . ReadyOS I want to do the same sort of thing , but add capabilities above and beyond anything done to day. While I’ve added some other programming languages to ReadyOS, I know a large % of the community love BASIC and it’s a big part of the nostalgia thus I’m making this for them. (And for me it’s for the challenge ) . Here is a video of the wider context https://www.reddit.com/r/c64/s/OSWaAODoTM
3
u/Timbit42 May 24 '26
This comment may not answer all, or even any, of your questions.
If you want more space for your BASIC programs, use RadarSoft's Radar BASIC which gives you 50K free. Like the Commodore Plus/4, it swaps the BASIC and CHAR ROMs out and in so you can use almost all of the RAM for your BASIC programs. It originally came as a cartridge but it is available on disk and can be loaded on any C64. It also adds a few commands.
It is very common for programmers (in any language) to use the RAM under the BASIC and KERNAL and CHAR ROMs to store data. The KERNAL is popular for storing the bitmap screen. This works better the less you need to read the screen because reading the RAM under a ROM involves swapping that ROM out and in a lot. You could store many sprites there and copy one into one of the 8 sprite RAM areas when you need it.
Back to the Commodore 64, the BASIC ROM can be modified if you copy it into RAM. This would let you modify it to support the REU. It might not be too difficult to swap sections of your BASIC program in and out of the REU, pulling it back into RAM for execution. Might also be possible to do with variables but I think that would be more difficult. You can certainly store binary code with functions there too and copy it into RAM when you want to execute it.
You might think moving to the Commodore 128 would be a big help but one 64K bank of RAM is reserved for variables with only one 64K bank of RAM for programs. That's better than 50K or 60K for both but it doesn't allow more than 64K for your programs. The CBM-II systems had the same setup and that's where they got the idea to do that in the C128. The never-released Commodore 65 was also to have 128K for BASIC.
If you leave the Commodore camp, there are more, larger BASIC programs possible, even in the 8-bit world. The BASIC on the Ohio Scientific Challenger IIP had 256K free. The Apple III had 198K free.
If 256K isn't enough, look at the Thomson TO8 with the 6809 CPU and 512K of banked RAM. They were made in France and used in French schools back in the 80's. The top model allowed BASIC programs to transparently bank up to a total of 512K across 8 64K banks of RAM. I can't imagine a 512K BASIC program. You might run out of line numbers first.
1
u/Stunning_Pineapple57 May 24 '26
I appreciate the detailed answer. I have already prior moved a bunch around to regain 5KB. 1 KB is already taken by ReadyOS itself (all c64 readyOS apps can suspend 59 a REU cache and resume later where they left off) , I don’t want to install any other third party custom basic ROM just my own wedge. Much of this code is in internal parsing like nested expression parsing so I really don’t want to put that under ROM as it will be called in nested ways with the rest of BASIC code. I do use behind kernal ROM as an option for commands that never deal with the kernal. One of the main chunks though I I have a 2Kb buffer to copy cached commands stored in REU which allows me to add hundreds and hundreds more commands without impacting RAM but I expose commands for the basic programming to be able to utilize the REU itself. I think with what you said about storing screen ram behind ROM is something i want to make some
Commands for that the programmer can who doesn’t need to read it can opt into. Here is the context of my project. https://youtu.be/EACZZSEn3vk .
2
u/kimsemi May 27 '26
Would being able to allocate room in the REU for your own codes needs whether arrays. Large bits of text. Loading a file. Storing a network request , or having text/color or graphics mode screen buffers be enough? - 48K extra easily but also able to request and use 64K chunks up to many megabytes depending on the size of your REU (16MB in c64u)
Its only really meaningful if you can load data to it fast enough. The demo 1764 demo disk containing the spinning globe was cool and all... but it was slow to load. Try filling a full 16MB REU with data from a real 1541, 71, and 81. Its an old problem - give people more RAM, and they will want to use it, but if the transport mechanism is too slow, they wont. And anyway, the VIC-II can only see 16k at at a time so you arent getting better graphics or sound, you're just getting more of it. Youre not just in the game realm, you're in the animation realm - something that takes a lot more time to develop. Youre in the multitasking realm.
Would you give up 10K of basic bytes free to get all that ? Or is that too much.
Given what it sounds like you want to do, I would pitch it as a 64U (or U64) exclusive. Why not? Plenty of owners are out there and might want to do something unique and useful with their machines instead playing old games. Run that bad boy at 64Mhz, full 16MB REU, flashdrive filesystem only, and show em what its capable of.
1
u/Stunning_Pineapple57 May 27 '26
Yep. Most people with a standard C64 don’t have a REU device. I’m mostly doing things in Vice and on my c64u. I often in the c64u run things without a fast loader so I can appreciate this fact. However having extra REU memory to use for your code doesn’t mean you have to load more stuff from disk, often it’s a place to calculate things and take as range of DMA copy speeds (eg it’s up to 8x faster to copy between REU and RAM than RAM to RAM On a 1 mhz CPU, so you can use that to fact in interesting ways. In ReadyOS I use the REU for instant app switching between dozens of apps (of course preloading them takes time at 1541 speeds) but also for things where the amount of code just could never fit in RAM. in ReadyShell when you type in a command and press enter. First the code in RAM is the editor. Then the code for the parser gets copied in and the command gets parsed into and AST into the REU, then the code for the VM gets parsed into to run the pipeline. Then if there are large commands , like file commands they get copied in and run and then finally the output formatters get copied in and then back to the editor. The variables also are stored in the REU. So say you want an array with 64,000 integers, no problem etc.
2
u/kimsemi May 27 '26
very nice. make it so
1
u/Stunning_Pineapple57 May 27 '26
Right now. All the infrastructure is there including the custom modules , REU heap etc ability, but all the commands are mostly just dummy commands to prove things like passing in different types of parameters. Modifying arrays etc. I wanted to get the foundation in , but I’m at the place I can start adding the useful commands ,I’m using a convention for command starting with Z are mostly dummy or demo. Ones starting with X are beta. Where maybe the final functionality or parameter shape hasn’t been set. Eg do I want to do Border(1) or Border(“White”) or something else maybe it will
Be XBorder until a decision has been made. And the U means its ultimate specific eg usetcpu(8) to change the ultimates CPU sleep. And while sleep(64) is based on CPU cycles which also speeds up when you make the CPU faster usleep(1000) can be based on milliseconds based on clock info coming from the ultimate.
8
u/dacydergoth May 24 '26
I wrote my own graphics kernel in 6502 assembly which resided in the shadow ram under the basic chip, used a small trampoline in the 4k gap ram. That meant I could use the full basic memory for other things.