I had a 128D with a 1570 REU running GEOS128 2.0, geoWrite 128, geoCalc 128, geoBase, and geoPublish. My wife did all her college papers in geoWrite. I did budgeting in geoCalc. I taught myself databases in geoBase. I put out a family newsletter in geoPublish… It truly was a great operating system.
BSW never released a GEOS ROM for U36. I did this in February 1999. If you get one from the original release (it's on Zimmers in cbm/firmware/computers/c128/other) and drop to MONITOR (hold RUN/STOP during reset) you can check out greetings to my scene contacts with 'T 480A0 48120 00400' command.
Ahh, that makes sense why I couldn't find any mention of it in dozens of magazines I looked through. Great info, thanks! I will have to check out your easter egg.
REUBOOT doesn't just reload state from the REU, it also checks to see if GEOS is still intact in the 128's RAM. First time you REU boot from a cold start it has to copy the GEOS kernel and such back into RAM from the REU. Next time you reset it the kernel is still in RAM. I believe it checks for a signature in a few places. I'm not entirely sure what it's doing with VDC RAM, but you also saw similar patterns while GEOS loaded from disk. Because VDC RAM access is indirect, but the VDC has some primitive blitter features, it likely preloads fonts and UI elements outside of the frame buffer. That is the only way to get fast VDC bitmap drawing. The kernel may also check to see if most of VDC memory has been preserved, and that may be the bulk of the delay when doing REU boot from a cold start. DMA from REU to system RAM is fast but loading VDC RAM is always slow. If I recall correctly, GEOS 128 couldn't use the VDC if you only had 16k of VDC RAM, so this makes sense. One easy way to test this theory is to run GEOS 128 in 40 column mode. How fast does it boot from a cold start when you're using the VIC? It may still set up the VDC if it is available tho, so you may still see a delay.
I can test the 40 column boot and see how it compares. My flat 128 has been upgraded to the full 64KB of VDC RAM. It still doesn't explain why the VICE REU dump works (the first time, anyway) without a big delay at startup and then falls apart the second time I try and use it though...
Yup, I learned the hard way about the 128's banking scheme... a few months ago as a learning exercise I made a B&W image viewer for the 80 column mode (and conversion program in Python), and first had to load the image into system RAM, then transfer it to the 128's video RAM. I kept wondering why part of my pictures would get corrupted until I figured out I had to use the MMU configuration register to swap out BASIC. It almost looks as if something is getting loaded into video RAM at 27:53 because you can see it writing line by line to the screen... possibly it's setting up stuff for the 8563 display chip (maybe for the desktop) until finally it kicks into the bit-mapped display...? It looks initially like it's in character mode because you can see the various blocks making up the screen and the 8563's character attributes like blinking, colors, etc. It would probably require a dive into the various GEOS programming books to see how its system works.
Ahh, I should have mentioned at 27:53 the screen corruption confused my video capture device for a moment which is why it looks all messed up and suddenly snaps to the desktop when it came up properly.
TY for the retro content! I really love when you do Commodore videos! When did you meet Bil and have him sign your C128? I bought his book arounds 6 months ago and I really enjoyed it. This is a GREAT video, and I love the editing where you highlight the paragraph on the page you are reading from. I know I told you this 4 years ago in the comments of one of the very 1st episodes, but I'll tell you again. You have a great voice for doing this. I'm looking forward to when you make the GEOS on the C64 video.
Thank you for the kind words, Charles! I met Bil at VCF MidWest in 2023 but I had previously arranged to bring my C128 to have it signed by way of his public Discord server. I read the book as well, it was entertaining!
Awesome video! I've often warned people away from the GEOS 128 option rom as it takes away boot drive configuration and kernal mod possibilities. This solution, if successful, would fix those problems. Of course, if anyone ever recreates the CMD RL, then we could cold boot GEOS in seconds also, but until then, this is very very promising.
There is a toolchain for making custom versions of the boot rom with the drive config and geos kernel of your choice. I still dislike it tho, and it isn't much faster than just booting from a 1581.
As you have device manager, try using that with a REU preloaded with GEOS128. DM should detect the rboot code in the reu, and add a GEOS ram boot option to its boot menu.
@@retrobitstv switching to 1mhz before doing things with the REU is a good idea. On vice you get away with not doing that, but on real hardware it is unreliable. On some machines it works with a UII+, but certainly not with a 'real' 17xx. It may corrupt memory or just crash the machine.
Minor Coincidence: I had a Star-NX1000C printer in the C64 days. I found it satisfying to see another Star printer referenced somewhere other than my memories.
Nice. I picked up an NX1000 a few years back as part of a lot so that's probably why I had GEOS set up with the driver. It works but it needs servicing as the belt slips a bit.
It’s really too bad Commodore didn’t release the C128 with a GEOS image on ROM sitting in that empty EPROM socket in 1985. Though I suppose that would have created competition with their new Amiga line.
What happens if you save the memory contents of a real CBM REU to a disk, power down, power back up, reload the contents of the REU using the memory dump file you just created, and then run rboot? My hunch is that you're going to see the same graphical glitching at first while rboot reloads the c128's main memory and re-initializes the display.
That would be something to try. I would have to write a program that read out the REU to a 1581 disk, nothing else would be large enough. Maybe something like that already exists; I'll have to take a look.
Great question! I noticed that also happens when exiting from GEOS back to BASIC, but I didn't dig into it while making the video. I do have a switchable JiffyDOS ROM in the system but am not aware of any C128-native software mechanism that would make this possible. My only guess is that GEOS is shadowing its own copy of the kernel into RAM but I'm not sure that's even technically possible and it surely seems far-fetched!
Thanks I didn't know much about GEOS but would love to use it. When you were booting and it shows garbage first, My first thought was that it just had the wrong start address and often the machine finally randomly makes it's way to the correct code and starts working.
Good eye! So I did a little digging and my VICE disk image is configured for the MPS803 while the real machine has the Star driver. Apparently, the selected printer driver is stored in the REU shapshot and when I loaded the VICE .reu file on the real hardware, that's what you saw. So my test methodology wasn't 100% apples to apples.
I wonder, did you dump one the images with the 128 desktop file in the ram disk, and the other not? Is the reason it loads so slow because the machine loads the file from disk on the first restart?
I was careful to setup both the VICE image and the UII+ REU the same way using the same GEOS .d81 image and both contained the Desktop file. I still haven't figured out the problem but I have poked at it a bit more since.
I profoundly dislike the 128 because it could have been something great if Commodore would have made it a C64 v2 (In the spirit of what the C65 later was) and not a 128 computer with a C64 built in. Commodore was very lost in the woods after the C64 and IMHO never recovered, and they did the same thing to the Amiga years later.
I don't know. Some things definitely went wrong with the 128's design IMO (like only just barely sort of fixing the floppy drive problem, designing the system around a CP/M feature that was mostly useless, limitations of the VDC, inability to use VIC in fast mode, etc.) and I do think C-128s often just ended up spending most of their time in C64 mode as well... However looking at it now I do think it was a good effort at making the C64 platform better for productivity, with the faster floppy drives, increased RAM, faster CPU and 80 column mode. It capitalized on the C64's success while addressing some of its weaknesses. I think addressing the C64's weaknesses was probably better than just building on its existing strengths.
Cool. Super interesting. I wonder if the fact that the U2+ REU emulation is not 100% compatible has something to do with it? If you run Maverick Goodies REU Tester with the U2+ REU installed it will fail and say there is a problem with the REU. Perhaps this is a bug and it needs an option or 2 to tweak the REU and settings for edge cases?
I doubt this, as it works just fine with the rboot 128 program, and C128 device manager (which includes detection for a GEOS128 preloaded REU, and if found, adds a GEOS RAM boot to its boot menu). I suspect the problem is trying to do the REU transfer while running in 2mhz. This works in VICE but does not work with a 'real' 17xx REU. With the UII+, it works with many but not all C128s, but is not supported. This has to do with when the REU releases the DMA line, and how long it takes for DMA to become inactive once released. Anyway, switching to 1mhz, like the manual for the 17xx REUs mention, will prevent this problem. The REU transfer speed does not depend on the CPU running at 1 or 2mhz.
I should clarify that the 128 RBOOT program suffers from the same 10-15 second screen corruption that my little reverse-engineered process does, again only with the UII+ snapshot and not the VICE snapshot.
I never was able to get one of these, did see Amiga once at a store and so wanted that as a kid. But yea never could. Wasn't until I did get a Used Mac Color Classic, wasn't a bad computer then later a Mac Clone then an iMac and a MBP. But was able to learn from it to the point where now I can build my own now and since 2010 since I felt Apple is being greedy, still feel like this to this day as well, even feel its worse now compared to then when I truly walked away from. Very interesting this computer though.
How does your BASIC program know where to put memory dumps from these binary files saved from the System Monitor, when you specify only a memory bank, but not the address? I would assume that commands should look like this: 10 BLOAD "1C000",B1,P49152 20 BLOAD "1FFF5",B1,P65525 30 BLOAD "03E4",B0,P996
To my understanding, the BLOAD command does a ",8,1" internally, loading to the original address it was SAVEd from. Providing your own start address would merely override this.
Not for this specific thing. There is when trying to actually run applications which are keyed to your GEOS install. However, if you create the REU image from that same GEOS install, that should not cause any issue.
What's funny is you are mispronouncing GEOS by pronouncing the same way as if you were saying DOS. In the early 1990s, I did the same thing but in reverse when I went from GEOS to DOS. What's odd is that you pronounce it correctly when saying "GEO-Paint", but you switch to the DOS pronunciation when saying "GEOS".
I had a 128D with a 1570 REU running GEOS128 2.0, geoWrite 128, geoCalc 128, geoBase, and geoPublish. My wife did all her college papers in geoWrite. I did budgeting in geoCalc. I taught myself databases in geoBase. I put out a family newsletter in geoPublish… It truly was a great operating system.
Wow... 8-Bit Show and Tell done to perfection!
Love the episode-long nod to Robin! Thanks for such a detailed and well-thought-out video!
wow, you have a commodore 128 signed by Bil Herd. You are so lucky. Thanks a lot. ❤
BEST CLOSING SONG EVER
Solid vocals there, nicely done! ❤
Your deep dives are a great watch. Keep them coming! The C128 was so underrated when it was released!
LOVE the song at the end!! :)
"R-E-U, R-E-U, without it my programs run like poo!"
BSW never released a GEOS ROM for U36. I did this in February 1999. If you get one from the original release (it's on Zimmers in cbm/firmware/computers/c128/other) and drop to MONITOR (hold RUN/STOP during reset) you can check out greetings to my scene contacts with 'T 480A0 48120 00400' command.
Ahh, that makes sense why I couldn't find any mention of it in dozens of magazines I looked through. Great info, thanks! I will have to check out your easter egg.
ROFL WTH, this 8-bit shown n tell video is... different.
Got my sub!
REUBOOT doesn't just reload state from the REU, it also checks to see if GEOS is still intact in the 128's RAM. First time you REU boot from a cold start it has to copy the GEOS kernel and such back into RAM from the REU. Next time you reset it the kernel is still in RAM. I believe it checks for a signature in a few places.
I'm not entirely sure what it's doing with VDC RAM, but you also saw similar patterns while GEOS loaded from disk. Because VDC RAM access is indirect, but the VDC has some primitive blitter features, it likely preloads fonts and UI elements outside of the frame buffer. That is the only way to get fast VDC bitmap drawing. The kernel may also check to see if most of VDC memory has been preserved, and that may be the bulk of the delay when doing REU boot from a cold start. DMA from REU to system RAM is fast but loading VDC RAM is always slow. If I recall correctly, GEOS 128 couldn't use the VDC if you only had 16k of VDC RAM, so this makes sense.
One easy way to test this theory is to run GEOS 128 in 40 column mode. How fast does it boot from a cold start when you're using the VIC? It may still set up the VDC if it is available tho, so you may still see a delay.
I can test the 40 column boot and see how it compares. My flat 128 has been upgraded to the full 64KB of VDC RAM. It still doesn't explain why the VICE REU dump works (the first time, anyway) without a big delay at startup and then falls apart the second time I try and use it though...
Yup, I learned the hard way about the 128's banking scheme... a few months ago as a learning exercise I made a B&W image viewer for the 80 column mode (and conversion program in Python), and first had to load the image into system RAM, then transfer it to the 128's video RAM. I kept wondering why part of my pictures would get corrupted until I figured out I had to use the MMU configuration register to swap out BASIC.
It almost looks as if something is getting loaded into video RAM at 27:53 because you can see it writing line by line to the screen... possibly it's setting up stuff for the 8563 display chip (maybe for the desktop) until finally it kicks into the bit-mapped display...? It looks initially like it's in character mode because you can see the various blocks making up the screen and the 8563's character attributes like blinking, colors, etc. It would probably require a dive into the various GEOS programming books to see how its system works.
Ahh, I should have mentioned at 27:53 the screen corruption confused my video capture device for a moment which is why it looks all messed up and suddenly snaps to the desktop when it came up properly.
TY for the retro content! I really love when you do Commodore videos! When did you meet Bil and have him sign your C128? I bought his book arounds 6 months ago and I really enjoyed it. This is a GREAT video, and I love the editing where you highlight the paragraph on the page you are reading from. I know I told you this 4 years ago in the comments of one of the very 1st episodes, but I'll tell you again. You have a great voice for doing this. I'm looking forward to when you make the GEOS on the C64 video.
Thank you for the kind words, Charles! I met Bil at VCF MidWest in 2023 but I had previously arranged to bring my C128 to have it signed by way of his public Discord server. I read the book as well, it was entertaining!
So basically the REU functions like Hibernation RAM.
Sorry, I only watched the first 30 seconds before I had flashbacks of DOS on my old IBM 5150.
Thanks for this very interesting exercise in Geos 128 hackery!
Glad you enjoyed it!
Awesome video! I've often warned people away from the GEOS 128 option rom as it takes away boot drive configuration and kernal mod possibilities. This solution, if successful, would fix those problems. Of course, if anyone ever recreates the CMD RL, then we could cold boot GEOS in seconds also, but until then, this is very very promising.
There is a toolchain for making custom versions of the boot rom with the drive config and geos kernel of your choice. I still dislike it tho, and it isn't much faster than just booting from a 1581.
Great video as always...
As you have device manager, try using that with a REU preloaded with GEOS128. DM should detect the rboot code in the reu, and add a GEOS ram boot option to its boot menu.
I will give that a try as well as making the snapshot in slow mode, thanks!
@@retrobitstv switching to 1mhz before doing things with the REU is a good idea. On vice you get away with not doing that, but on real hardware it is unreliable. On some machines it works with a UII+, but certainly not with a 'real' 17xx. It may corrupt memory or just crash the machine.
Thanks for sharing. Cheers.
Minor Coincidence: I had a Star-NX1000C printer in the C64 days. I found it satisfying to see another Star printer referenced somewhere other than my memories.
Nice. I picked up an NX1000 a few years back as part of a lot so that's probably why I had GEOS set up with the driver. It works but it needs servicing as the belt slips a bit.
Oh man the payoff at the end! Standing ovation
I remember being confused when I tried GeOS on my C64. A GUI was a new concept to me.
Haha understandable! Without a mouse it would have been pretty awkward to use as well...
Yes, some 128 love! Would love to see the 64 version too!
This was cool Matt, thanks.
I have MIB 128 with matching 1571. Makes me want to get it out and do more than Zaxxon with it. Kudos!!
RAM 'disk' is etched in my brain as an Amiga user♥️
Great video, thanks 😊
I got my first C128 in 1989, ya young whipper-snapper. ;D
Haha, that's about the time I traded my 64C for a used 128 as well. I wish I had kept it :(
@@retrobitstv That's about the time I went from a breadbin c64 to DOS machines.
I was still using a C64 at the time, bought years earlier with summer job money.
C128 machines were the best, nice design with dual cpu
It’s really too bad Commodore didn’t release the C128 with a GEOS image on ROM sitting in that empty EPROM socket in 1985. Though I suppose that would have created competition with their new Amiga line.
What happens if you save the memory contents of a real CBM REU to a disk, power down, power back up, reload the contents of the REU using the memory dump file you just created, and then run rboot? My hunch is that you're going to see the same graphical glitching at first while rboot reloads the c128's main memory and re-initializes the display.
That would be something to try. I would have to write a program that read out the REU to a 1581 disk, nothing else would be large enough. Maybe something like that already exists; I'll have to take a look.
Great video! How come when you cold boot, I see JiffyDOS copyright, but when you hit reset button - no JiffyDOS?
Great question! I noticed that also happens when exiting from GEOS back to BASIC, but I didn't dig into it while making the video. I do have a switchable JiffyDOS ROM in the system but am not aware of any C128-native software mechanism that would make this possible. My only guess is that GEOS is shadowing its own copy of the kernel into RAM but I'm not sure that's even technically possible and it surely seems far-fetched!
Thanks I didn't know much about GEOS but would love to use it. When you were booting and it shows garbage first, My first thought was that it just had the wrong start address and often the machine finally randomly makes it's way to the correct code and starts working.
nice computer, cool video.
(@24:56) - well, that’s weird. Last time it saw a Star printer, but this time it sees an MPS803??
Good eye! So I did a little digging and my VICE disk image is configured for the MPS803 while the real machine has the Star driver. Apparently, the selected printer driver is stored in the REU shapshot and when I loaded the VICE .reu file on the real hardware, that's what you saw. So my test methodology wasn't 100% apples to apples.
I wonder, did you dump one the images with the 128 desktop file in the ram disk, and the other not? Is the reason it loads so slow because the machine loads the file from disk on the first restart?
I was careful to setup both the VICE image and the UII+ REU the same way using the same GEOS .d81 image and both contained the Desktop file. I still haven't figured out the problem but I have poked at it a bit more since.
REU kidding me?
😂
I profoundly dislike the 128 because it could have been something great if Commodore would have made it a C64 v2 (In the spirit of what the C65 later was) and not a 128 computer with a C64 built in. Commodore was very lost in the woods after the C64 and IMHO never recovered, and they did the same thing to the Amiga years later.
I don't know. Some things definitely went wrong with the 128's design IMO (like only just barely sort of fixing the floppy drive problem, designing the system around a CP/M feature that was mostly useless, limitations of the VDC, inability to use VIC in fast mode, etc.) and I do think C-128s often just ended up spending most of their time in C64 mode as well... However looking at it now I do think it was a good effort at making the C64 platform better for productivity, with the faster floppy drives, increased RAM, faster CPU and 80 column mode. It capitalized on the C64's success while addressing some of its weaknesses. I think addressing the C64's weaknesses was probably better than just building on its existing strengths.
Typical Commodore, they wasted so much time on side quests instead of just making better computers.
Cool. Super interesting. I wonder if the fact that the U2+ REU emulation is not 100% compatible has something to do with it? If you run Maverick Goodies REU Tester with the U2+ REU installed it will fail and say there is a problem with the REU. Perhaps this is a bug and it needs an option or 2 to tweak the REU and settings for edge cases?
I doubt this, as it works just fine with the rboot 128 program, and C128 device manager (which includes detection for a GEOS128 preloaded REU, and if found, adds a GEOS RAM boot to its boot menu).
I suspect the problem is trying to do the REU transfer while running in 2mhz. This works in VICE but does not work with a 'real' 17xx REU. With the UII+, it works with many but not all C128s, but is not supported. This has to do with when the REU releases the DMA line, and how long it takes for DMA to become inactive once released. Anyway, switching to 1mhz, like the manual for the 17xx REUs mention, will prevent this problem. The REU transfer speed does not depend on the CPU running at 1 or 2mhz.
I should clarify that the 128 RBOOT program suffers from the same 10-15 second screen corruption that my little reverse-engineered process does, again only with the UII+ snapshot and not the VICE snapshot.
I never was able to get one of these, did see Amiga once at a store and so wanted that as a kid. But yea never could. Wasn't until I did get a Used Mac Color Classic, wasn't a bad computer then later a Mac Clone then an iMac and a MBP. But was able to learn from it to the point where now I can build my own now and since 2010 since I felt Apple is being greedy, still feel like this to this day as well, even feel its worse now compared to then when I truly walked away from. Very interesting this computer though.
Wow. I have a 128, and a 128D, never tried GEOS on there only ever used C64 version. Will need some sort of modern REU implementation I guess.
Check out the RAD Expansion Unit project!
31:00 *The* John Diliberto? If so, that's one hell of an endorsement/patronage!
I see no attribution for the end-song, so, I'd guess... suno?
Congrats on being one of only 13% of viewers that stick around for the credits! Yea, I wrote the lyrics and fed them into a similar AI tool.
for moving data the REU takes 2 clocks per byte
How does your BASIC program know where to put memory dumps from these binary files saved from the System Monitor, when you specify only a memory bank, but not the address? I would assume that commands should look like this:
10 BLOAD "1C000",B1,P49152
20 BLOAD "1FFF5",B1,P65525
30 BLOAD "03E4",B0,P996
To my understanding, the BLOAD command does a ",8,1" internally, loading to the original address it was SAVEd from. Providing your own start address would merely override this.
@@throwaway6478 if that is true, then ok, it all depends on the format of the dump. If it is a raw binary dump, then there are no addresses in it.
@@throwaway6478 Yes, that is correct.
From the first 2 bytes in the file.
@@c128stuffYep, hence why you have to specify the bank (because that isn't stored in the PRG).
wow and zamzam water
lol my brain thinks that's a weird looking Atari ST.
Is there any copy perfection schemes going on?
Not for this specific thing. There is when trying to actually run applications which are keyed to your GEOS install. However, if you create the REU image from that same GEOS install, that should not cause any issue.
nice i have dave haynies a1200 that i also had him sign
pics are online because its a rare rev 1d
What's funny is you are mispronouncing GEOS by pronouncing the same way as if you were saying DOS. In the early 1990s, I did the same thing but in reverse when I went from GEOS to DOS. What's odd is that you pronounce it correctly when saying "GEO-Paint", but you switch to the DOS pronunciation when saying "GEOS".
FIRST!
Second, over an hour later hehe