Commodore 64 REU (RAM Expansion Unit) & SID Random Numbers
Vložit
- čas přidán 10. 06. 2024
- Demonstrating the various RAM Expansion Units (REUs) available for the Commodore 64 and 128, including how to program them to help in analysis of the output of the SID's noise waveform.
Become a patron: / 8bitshowandtell
One-time donation: paypal.me/8BitShowAndTell
An article I wrote about REU programming many years ago for Loadstar Letter: psw.ca/robin/?page_id=182
More info about the C64 game Sam's Journey: www.knightsofbytes.games/sams...
More info about Jim Brain's X-Pander 3 expansion port... expander: www.go4retro.com/products/x-pa...
The memory map images I used in this video are from the Commodore 64 Programmer's Reference Guide, which you should be able to find in electronic form easily with a search.
Some images also from the "Commodore 64 1764 Ram Expansion Module User's Guide":
archive.org/details/Commodore...
Stand-alone video of A Procedurally Generated Christmas Song: • A Procedurally Generat...
Follow me on Twitter: / bedfordlvlexp
Check out my podcast Growing Up '80s: thecouch.website/category/gu80s/
Index:
0:00 Happy New Year intro
0:56 Snowflake Randomness & LFSRs
5:37 Pulling random values from SID
8:30 Introducing RAM Expansion Unit: REU & Expanders
15:26 Sam's Journey - uses REU on NTSC
18:26 Exploring REU memory with Super Snapshot Monitor
20:29 Programming the REU to do a transfer
28:42 Executing and analyzing the REU transfer from SID
35:00 Back to the random snowflakes
37:52 A Procedurally Generated Christmas Song - Věda a technologie
Once upon a time, nobody would dare saying "I know about computers" without knowing a second "high level" language besides Basic, and having at least some assembly knowledge. Pascal and assemblers like Merlin or Turbo Assembler were more or less mandatory, or else you were just a gamer. Nowadays people think they are "computer freaks" just because they can do trivial things on Excel . Ah, the old good days, when men were men...
On a more serious note, this is great video. I learned a thing I wasn't aware of, and it was explained in detail.
Oh Robin! I wish you would put together an absolute beginners and up series of videos on stock C64 gear. The way you explain and complement your content with memory maps and lucid language is elegant.
Thanks! I've been getting a few requests for making beginners videos. What sort of information would you find helpful? BASIC or assembly programming? Or something else?
Since the SID oscillator is independent of the processor, discrepancies in the polling of the SID (since the oscillator isn't precisely timed with the main clock) could produce effectively random (not repeatable) errors, like you demonstrated.
It's really cool! This sort of polling-a-slower-machine is used everywhere in computer security, to generate entropy bits for priming pseudorandom number generators! If you've ever had a program tell you to move the mouse around for apparently no reason, it's using that kind of polling to increase entropy, which makes the PRNG better at RNG-ing! Additionally, some systems will keep track of polling discrepancies and give them to you when you ask for a random number (The CSPRNG behind /dev/random and /dev/urandom on *nix systems does this!)
I'm far from an expert on this sort of thing but it's a really, really neat way of generating entropy!
This channel is a C64 lover's wet dream :) I can't get enough.
TI 99/4a house here. But it is good to know the enemy.
I can laugh maniacally at your weak floppy drive performance, while you laugh maniacally at my ... weak everything else performance. Well, shit, that didn't work right. Ummm, at least I have a sixteen-bit processor?
...
Seriously, though. This is all interesting stuff, and I appreciate knowing how the other half(nine-tenths?) lived.
@@CptJistuce I love all 80s computers. The TI was very nicely manufactured. Such as shame TI tried to kill off all third part access to it.
Very interesting episode about the REU and great teaching !
Before detailed pictures of the SID die were available for analysis of the actual logic, OSC3 & ENV3 were used to emulate most of the internal behaviors of the SID in a cycle-exact way, which made reSID possible. It was a big deal when it came out in the late 90s because it fixed a lot of problems like "ADSR delay bug" and "ADSR boundary bug". Suddenly SID emulators based on reSID sounded much more faithful. Sampling OSC3 also allowed finding noise periodicity and LFSR logic but it could not explain how combined waveforms were generated from logic as it involves analog stuff !
Your idea about the extra cycle is correct. A voice accumulator is 24bits, each cycle the 16bits freq is added to it. The noise logic generates a new value from its LFSR when bit #19 of the accumulator is set to 1. To get a quick idea, this happens in average every 2^20/freq cycles, with freq = 0xffff it's exactly every 16.0002441444 cycles "most of the time 16, once in a while 17"
Thanks for the awesome info! I'm interested in learning more about combining the waveforms. Years ago I made a SID-detect routine that used combined waveforms to decide if it was 6581 or 8580 but only partly understood what was going on ;)
@@8_Bit I don't know the details of what's going on at the analog level when combined waveform are enabled, on the 6581 most of them produce 0 output except the #5 waveform (triangle + pulse) which produce this very strange complex SID-specific waveform ( Flight Path 737 title czcams.com/video/hCjmzaED-8k/video.html )
Maybe you have used a specific combined waveform that produce 0 on 6581 and non zero on 8580 and sum a few output of OSC3 and see if the result was 0 or so ?
@@laurent64 I now remember that my routine ended up in C= Hacking text magazine. If you search for "SID Type Auto-Detect" in www.ffd2.com/fridge/chacking/c=hacking20.txt then you'll see my code. It looks like I combined the triangle and sawtooth waveforms, maybe not the most reliable way?
@@8_Bit it should be quite reliable, in your code you say it's not 100% though ? on 6581 the higest value is 3F and on 8580 it's FF with a lot of values > 80 so i would think your detection works all the time ? maybe you could set and clear test bit of d412 before starting the detection to make sure accumulator starts at 0 ?
@@laurent64 I think it worked reliably in my tests but due to the variation in the numbers returned I felt like once in a while it might get unlucky (lots of low numbers returned) and would detect 6581 when really it was 8580. I don't think I realized the max value was 3F from the 6581.
Nice. I think what this video demonstrates very well is that assembly language programming on the C64 is more about knowing the hardware than the language. I see many people on the internet asking about what it takes to learn assembly, because they think it's difficult. I don't think it really is. The magic is in what the hardware can do.
I'd like to see a run down of your snow flake program.
Yeah, the assembly language itself isn't difficult, it's knowing the hardware as you say, and also being able to see both the big picture and the extremely small details at the same time as we try to build structure and make things happen with these extremely granular instructions.
@@8_Bit Right, you have to have a plan before you begin to attack complex problems. The documentation isn't always clear, but when you know where to look, it's all there. The internet is very helpful for sharing solutions and different approaches.
I have been learning Z80 assembly language on the Sinclair ZX Spectrum over the past several years, and I agree; the actual machine architecture is *AT LEAST* as important to know as the mnemonics and what each instruction can do.
Now it's time for me to try my hand at 650x Assembler! 8-O
@@BertGrink I've been trying to get into Z80 assembly language, but I can't seem to get my head around all the registers and shadow registers!
@The Highlander Yeah it does take some getting used to; I think I was lucky insofar as I had had a Texas Instruments programmable calculator before I got into the home computer/microcomputer thing. This helped me a lot in understanding how those Sinclair machines worked.
Anyway, don't worry about the 'shadow' registers in the beginning, their original main purpose was to enable very fast context switching when handling interrupts, and I don't think you should start with that.
Instead, do some simple stuff like loading different values into different registers, adding or subtracting and such.
Here's a short addition example:
LD A,$20 ; puts the value hex 20 (32 decimal) in the accumulator
LD B,$10 ; puts hex 10 (16 decimal) into register B
ADD A,B ; add them together; A should now hold the value $30
RET ; all done
Multiplication is pretty easy too, it's essentially just repeated additions; let's say you want to multiply 115 by 5:
LD BC,5 ; BC now holds the multiplicator
LD DE,115 ; DE holds the multiplicand
LD HL,0 ; HL is sort of a 16-bit accumulator, which we clear here
XOR A ; clears the accumulator and resets the carry flag
LoopDaLoop: ; just a label
ADD HL,DE ; adds the multiplicand to the subtotal
DEC BC ; decrement the multiplicator
LD A,B ; check if multiplicator
OR C ; has reached zero
JR NZ,LoopDaLoop ; if not zero, perform next addition
RET ; done
Of course, floating point arithmetic is a completely different kettle of fish, but most 8-bit computers will have some sort of built-in library of routines for that. Modern CPUs don't have that problem, as they typically have an FPU (Floating Point Unit) as well as integer capabilities.
That's an EXCELLENT explanation of how to get random numbers via SID registers. Nice video.
@Robin - Did you ever happen to do an episode looking more closely at LFSR's? I looked but didn't see one and would be really interested in learning more about them. Thanks!
love your channel. youre doing the channel I always wanted to do but never did! Sam's journey is awesome...didn't know it needed an REU for NTSC.
Another option for a REU is the 1541 Ultimate cartridge. Beside a lot of other features it includes REU emulation.
Impressive RAM expansion units. And here I hoped for you to make a "Dave" (from EEVBlog). -"Don't turn it on. Take it APART!"
The random number update makes sense. 0xFFFF programmed into in the SID frequency counter represents ca. 65Khz. If the REU is reading every 1Mhz, then it will read the same value 16 times before the SID updates. I love it when something computes!
Yes the frequency register of the sid is added to a 16bit counter every clock cycle, and whenever it wraps the next "wave pulse" starts, or in this case a new random number is chosen. So yes if it had been able to be set to 65536 it would have been exactly 16 times for each value. If it was set to 32768 it ought to repeat each value exactly 32 times. With 65535 it should have one extra repeat every 64k clock ticks, exactly as was seen.
Grate video. Just getting back in c64 .since 1980s
Hello Robin. I did that same tests with my Nano SwinSID installed on a C64 (250425) BreadBin using a Ultimate II+ cartridge as the REU and a Super Snapshot Cartridge also emulted by the Ultimate II+ and it would seems that the Swinsid timer is not as predictable/regular as the real one. I get no regularity in the number changing and I also get many zeros. Maybe my choice of emulated equipment renders things incompatible with the real stuff. (Or maybe I have reach my Peter's limit LOL) Anyway, your channel is among the most interesting of the genre. I did my share of assembly programming on the 6809 and the 8088 using debug, edlin and other rudimentary tools in the days. It is only now that I get to experiment on the commodore stuff and your channel is much instructive and of great help. Keep on the great work. It is very generous of you. Best Regards.
Hi Daniel, that's very strange and interesting that the Nano SwinSID would give such different results, or perhaps it has something to do with the Ultimate II+ REU emulation? If I get a Nano SwinSID installed someday I'll have to test this with a C= REU. Thanks for the info.
Great video, very informative. By demonstrating that SID takes 16+ cycles to change when using for random numbers, I was able to correct a coin flip demo video on my own channel so that the results are now 50-50 as expected. As noted below it's as much about knowing the hardware as it is knowing assembler or BASIC. I look forward to more assembly/hardware tutorials.
I’ve been studying up on the 64 a lot the past month, I can tell it’s working because this video is starting to make sense! :D Hey you should start a Patreon, I’d love to support more of these!
Thanks! A Patreon would be interesting, I'll definitely think about it.
Fantastic demonstration of how to use an REU! I had a 1764 and remember that GeOS was the only software that would leverage it -- but even then, it would only be used as a RAM-disk. Since CMD's superior REU came out in 1997, it isn't surprising that no new retail games were written to support it.
At the time, there was also a text file in circulation showing how to modify a Commodore REU to boost it to 2MB (or 4MB?) by stacking various RAM chips on top of one another and making the required connections to traces on the board. You can imagine the quality of schematic in that file -- all done in PETscii! If I am not mistaken, the 1764 circuit board has several spaces where additional RAM chips may be added, effectively turning it into a 1750.
Pulling a value from a free running oscillator like that works like Sample and Hold on analogue synthesizers. It takes the current voltage at a certain point in the oscillator cycle and holds it for a finite amount of time - you apply that voltage to another oscillator, filter, amplitude or any combination of the three. It's how classic Sci-Fi "bleep bloops" are created, including, I think, the random beeps from R2D2 (which used an ARP2600).
If you slowed it down and applied the value to the pitch of oscillator one set to a square wave, you'd get instant Sci-Fi! I might have to try that. :)
Excellent video!
Love your videos, great respect.
As a new C128DCR owner I find this very interesting.
Over the past month or so I have bought the following stuff on ebay:
The aforementioned C128 with a mouse, joystick and video cables;
A Commodore 1750 REU;
An MPS1230 printer;
Several systems- and utility programs on diskette;
a Datasette unit;
and finally, an 1084S monitor.
Oh and I almost forgot, Simon's BASIC on cartridge.
I think this is a pretty neat setup, wouldn't you guys agree?
@8-Bit Show And Tell Aww thanks for the hearts!
That's a very nice system you have, enjoy! :)
God, I wish I had the REU. When I was a kid, I remember reading how it would "Turbo-charge" GEOS, which was my go-to operating system in the mid 1980's to around 1995. Ha! Now that I think about it, only Windows 95 was able to replace my beloved GEOS!
“I’ve never opened one of these up to see what exactly was in there.” I would have done exactly that on day 91 (assuming a 90-day warranty).
Really interesting. Nice job.
So these expansions were actually only used as a ram disk, and not when running a program. I have a small 8 bit processor on a breadboard and am looking into epanding the RAM up to 16 megabytes. A unique feature of the processor would allow me to actually emulate a simple MMU in software and call subroutines (almost) anywhere in this expanded memory space..
The occasional 17-cycle sample occurs because you only set the noise frequency to 65535, not 65536. (Indeed, you can't set it to 65536 because the register is only 16 bits wide.) I bet if you set the noise frequeny to 32768, then you would consistently see your random numbers persisting for *exactly* 32 cycles every time.
I never realised there was so much to the REU. Amazing device, a shame I knew nothing of it at the time.
I love the explanation and knowledge in this debug technique. Totally worth it. I would have just removed the no ops annd found the limit. Then I would not have learned as much.
the December 2021 released C64 port of SEGA Sonic the Hedgehog requires a REU with minimum of 256KB memory to be able to run. So that high performance DMA capability was in a way just as much a feature as the additional memory itself
You are good at this and know the architecture well! Did the reu sample the random number for every cycle?
Yes, the REU sampled the SID's random number output every cycle, for 65536 cycles which is the maximum length of an REU transfer. I cleared bit 4 of $d011 during the transfer so that the VIC badlines wouldn't interrupt the REU at all.
I had to come back and revisit this video. Now that Sonic for the C64 is out (which an REU is a must) and Sam's Journey (NTSC requires REU), I hope we start seeing more REU inspired games. In my game, I've decided to support REU for more advanced features such as full screen scrolling with color and NTSC. With VICE and a few devices these days for REU, I'm hoping the trend will take off a little. Now, nothing beats a great, optimized C64 running on the stock system...but REU's can definitely add a new area of gaming for the C64.
that song at the end LOL!
😋😃
Using a RAM expansion unit as a piece of test equipment - Genius! Loved it!! Possibilities include capturing pulse trains into the USER port and analyzing the repetition rate using the same method as viewing the SID chip's output. A storage oscilloscope would achieve basically the same measurement, but because of the limited screen resolution, you cannot see the exact number of microseconds between pulses. I have some programs that use the USER port for data acquisition and control, using optoisolators to couple the outside-world circuitry to the C64 or C128. Could you make some tutorial for others as to how to use the User port to interface the computer to other devices? Thanks for very good presentations. GB
The other thing about an oscilloscope is that it probably wouldn't sync exactly to the CPU, which runs at ~1.02 MHz on an NTSC C64. So cycles and microseconds aren't exactly the same thing.
A user port episode would be interesting, thanks for the idea.
These are all interesting, I even had a few. I wish I could get my hands on a old pet 64 with 2 SFD 1001 Drives mounted internally. That was my goal till life changed and lost it all.
Love 6502/6510 assembly. I doubt this would confuse anyone, it shows how nice it is. Load values into the accumulator (LDA) then alter them and store them (STA) into some memory register. Something else you could program, and I don't know if you ever touched on this, was the Commodore floppy drives like the 1541, it actually had it's own computer inside of it with a few commands of it's own. I once wrote a "virus" (not really but) which would disable a single bit on a floppy disk making it unreadable. I didn't share it with anyone, I was just messing around, but a friend of mine was curious about it so I gave it to him with the warning about what it did. Later on, he forgot what it was, ran it with his favourite floppy in the drive and he could no longer read from it. So he threw the floppy disk away and I told him he should have told me as restoring the disk was just as simple. Anyhow, just a fun story from the days when I learned about that. :)
I've been meaning to do an episode about how fast loaders work, and that would involve programming the disk drive. The closest I've done is the episodes about Animated Disk Directories, and the Epyx Fast Load one. I made one disk unreadable by editing the DOS type byte with the disk editor!
One note about the REU bank register..
Writing to this register always works as expected, but reading does not. The value returned by it will always at least be $f8 because all the high bits always return 1, even on an expanded REU (official, ie CMD 1750XL, or user upgraded Commodore 17xx).
nice channel. you got my sub :)
Grate video
So my son is watching the tail end of your video with me and he asked if we could watch your procedural Christmas song (not by name) and lo! there it was at the end of the video.
Haha, that's great, thanks for sharing :)
You should try and find yourself a Mini Chief 1571 drive. It was a kit or a complete unit were it had either a 20 or 40MB minicheif HD inside a 1571 floppy drive. The floppy drive worked, and with the HDD you had a choice of breaking the drive into x number of 644k partitions or have it as one large one. (I think it was 644k per floppy normaly??).
I had no idea the REUs used DMA and could copy that fast! J thought they could only bankswitch into a fixed area
Just wondering : Have you done an episode on LFSR ?
I haven't done an episode on LFSR yet, but it's on my list! If only I could make videos faster :) I've got a LFSR example I wrote in BASIC and a couple games that use them.
Well, I look forward to it when it happens :)
Jingle Horse sounds nice
Do you have a link to the info on the RNG used in river raid? Was it part of a “making of” documentary or a post Mortem speech by the programmer? Where can I find it?
I learned about it from the "Stella at 20" documentaries which I bought on VHS and watched years (decades) ago now, so I don't remember exactly where. You should be able to find them here on CZcams. It was probably David Crane who talked about it, or possibly Carol Shaw. I think Crane was primarily responsible for the technique even if Shaw was the programmer on River Raid.
I LOVE C64 👍🥂🎩
Excellent intro into the REU! It seems pretty powerful. I see that it isn't limited to reading from the C64's RAM - it can also read from the C64's IO-memory (such as $D41B as you show in the video). Can it also write to the IO-memory? I wonder if the REU makes it possible to abort an already started badline (change $D011 after the VIC has taken over). Or is the REU also blocked by the VIC during badlines, like the CPU is? I've always wondered what would happen if an already started badline was aborted... Anyway, very interesting! :)
EDIT: I wrote this after having only watched the first 25:00 minutes of the video, and i guess you answered my question a few seconds later ;) So not possible.
(But it looks like it can be used to set up IO registers many times faster than the CPU (1 write pr. cycle), so cool VIC-tricks must still be possible with it, that aren't possible without it!)
I'm almost positive the REU can write to C64 IO space, though I'm not sure I've ever tried. I've definitely tried reading $D012 and have a video planned about that, as it's interesting how we can analyze the cycles per scanline and scanlines per frame characteristics of the various VIC-II versions that way.
@@8_Bit Looking forward to it! :) Yeah, it's actually pretty amazing - i'm really surprised by the power of the REU! A really good tool for analyzing the behavior of the IO-chips - and (assuming you can also write to IO) an amazing tool for making the VIC do impossible stuff! (Like for example (simple example) 1 cycle wide raster-splits, by making it write to $D021 or $D020. Crazy!). Thanks for the introduction :)
Yes you can DMA to and from I/O but according to Groepaz it is unreliable. Details are posted at csdb.dk/release/?id=144105 which also happens to be the release page for Treu Love an incredible REU based demo.
Here's a n00b question as it relates to REUs. If you had a 1750 plugged into your C128D, then entered C64 mode to play a game (like Sam's Journey) does it properly see and use the REU accordingly?
Yeah, all the models of REU (1700, 1764, 1750, CMD 1750XL) work in both C64 and C128 mode, and also work on a regular C64. The only thing is making sure you use a heavy-duty power supply on the C64, as the REUs draw more current than a regular C64 brick can supply safely.
I think it's just that you don't have interrupts locked and when making an interruption I don't update the new random in time and keep the previous value for a few more cycles
Hi. What's the range of output from the OSC3 noise? I noticed that nearly all the values you got were over 100. Was that just an unusual bit of randomness or is the range restricted or skewed in some way?
Hi, it gives a very even distribution through its 8-bit range from 0-255, but when I was PEEKing it in BASIC around 7:00 they did tend to be over 100, and I was also printing over the old numbers which made the actual results unclear. For example, that 557 was actually a 55 printing over the old 3-digit number that ended in a 7. Later in the video, around 32 or 33 minutes in, you can see a wide range of values in hex. Anything less than 64 hex is less than 100 decimal.
Do you have any current alternatives to the CMD reu 512k. They are difficult to find now days. Enjoying your content
Look into the 1541 Ultimate and Turbo Chameleon. I don't own either, but have heard they have REU functionality. Make sure you research before you buy though! :)
The SID has a random number generator? Damn, I could have used that years ago.
Are there DMA REU made now out there? I am watching Ebay and Etsy for one (searching for CMD REU)
I had a 512K one expanded manually to 1 Meg by a friend of a friend who I bought it from. Dont remember if the power supply was part of my used purchase. Not sure what I wanted it for, I eventually used it as a disk to download to with my terminal emu. Kind of risky, but never lost anything to a power out far as I remember, but yeah, wasn't much of anything to do with 'em.
just to point out that the ntsc display was a lower resolution, and the pal c64 ran slightly slower. It wouldn't be as hard as you imagine to get those extra frames. What it works out to is that an NTSC system has two more processing cycles per scan line.
The NTSC TV might have a lower resolution, but the programmable screen is always 160x240 color or 320x240 grey pixels, PAL or NTSC.
Wouldn't mind a schematic and block diagram for the REU
are there different games available for c64 with more rams ?
LOL the c64 singing :-D too funny
Psuedoradom number generation, not 'true' random number generation. Many BASICs have a 'problem' that the RNG function can be decidedly non-random over time under the right circumstances. Most correction methods I recall use the system clock in combination with user input timing to mix up the RNG seed.
I wonder, wouldn't a loop do the trick? increment a number with each cycle and print the peek on the screen followed by the number, after a while you should see how many cycles it takes before the peek number changes.
BASIC would be too slow to do this. You definitely would get a new value EVERY time, but what you would NOT know is that between readings, hundreds of other values were already generated and discarded. It's possible to catch the SID readings quickly enough on a stock 64 without an REU using machine language. You would need to then examine the raw results knowing how many cycles it took to fetch each sample, versus the 1 cycle per sample convenience the REU provides.
Were those pet computers same format on a diskette as a IBM vice versa? They can read on each machine. I know they not work on a Commodore 64.
I was thinking, perhaps you could grab random numbers at random intervals based on the same SID generator for even more randomness. heh
Great video, thanks for this. I dusted off my "Check for REU" Basic prog. It just checks for the existence of an REU, not sure if it works with all expansion carts though. 100 is just a test value at $DF02, one could use any value:
10 POKE 57090,100: IF PEEK(57090)=100 THEN ?"REU Detected"
Hi, yes, that should be a fairly reliable method. It might produce a false positive if there is a different device mapped at $DF02 that still behaves like RAM, or a device that coincidentally returns the magic number chosen (such as 100 in this case). The 2nd case could be eliminated by storing one magic number, checking for it, and then storing a second, different magic number, then checking for that :) The first case could only be fully eliminated, I think, by actually triggering an REU transfer and then checking for the results. Would it ever really matter? Probably not, I just like to think through these things :)
I've been content with trusting the SID to create random numbers since the 90's. But it's just a LINEAR FEEDBACK SHIFT REGISTER?!? My mind is blown. I always assumed it was reading static from the power line or something unreproduceable like that. If the register is 23 bits wide does that mean it has a 23-bit cycle (8MB of data) before the pattern repeats?
REU doesn't seem that confusing. A bit clunky and involved compared to say like an Amiga A501 expansion (which just adds additional addressable RAM to the mostly empty space of the 68k in that machine), but it's no worse than an "expanded"/EMS memory card for a PC. Anyhow, I love that snowflake/snowfall thing. I'm a winter person afterall heh.
255 & 255 for the sid comes with the problem it's not $1000, one too little. Every overflow on accumulator is a tick for the sid. Adding $ffff overflows 99.99% but not that time when accumulator is at 0. So you get 1/65,536 miss alignment.
The DDS (direct digital synthesizer) works that way. Use a variable (in this case more than 16 bit i guess 24 bit) add the low and the hi byte to the variable and you get a variable sawtooth frequency. With that sawtooth you can calculate a triangle or a square, but you can also use a lookup table to play samples or other waveforms. Mostly you use the most upper bits for the waveform.
phase+accumulator is pretty much a divide by any number pre-scaler, instead of just power of 2, but the problem is jitter if you don't use phase numbers that is power of 2. $8000 would be jitter free but would be half the speed, $ffff is nearly jitter free, not just that time when it takes two of them to get a roll-over tick that happens 1/65535.
One more quickie. If you have a PSU that provided more amperage, and the REU pulls those amps across the 64's motherboard, could it harm the 64? I ask because in circuit design, you have to be careful about amperage and heat dissipation. Too many amps across a small trace will fry it. The PSU will not limit the amperage, only voltage. The device (e.g., REU) determines the amp draw.
Or does the REU meant for the C64 have a seperate DC power input on it? Asking for a friend. :)
Seeing how Ray Carlsen makes a 5A C64 power supply with overload (in addition to over voltage) protection, I would guess 5A is safe to run through the C64?
I'm not much of a hardware expert, but I know I've used the 512K REU on my 64C, with a heavy duty power supply, for many extended coding sessions without any problem. The REU is powered through the expansion port, there's no separate power input on it.
The power supply included with the 1764 REU provides 2.5A on the 5V line and it's enough. But if Ray Carlsen makes a 5A power supply, it must be safe. I'd trust every Commodore I own with him :)
I wouldn't worry about burning out traces, that generally comes down to component failure and Commodore 8 bit machines have stood the test of time.
I think you've misunderstood why Mr Carlsen appears to use an over specified PSU. From his site, "If you are making your own power supply, the +5VDC should be able to source at least 2.5 Amps for a C64 and 5 Amps for a C128. Since the cost for each switcher module is about the same, I use a 5 Amp module so my PS can run any Commodore computer."
Keep in mind that the PSU's Commodore included with the REU were designed to power a C=128 hence the higher rating, they were also switching supplies and not susceptible to the well known regulator failure that kills 64s.
I really wish the SS monitor had some indicator that you were on the REU like the monitor on the 128 does. I've been confused about where I was several times lately because of this.
I'm trying to remember, on the 128, it shows the bank number before any 16-bit address, making it look like a 24-bit address? Hopefully Adrian and/or I can make some improvements to the SS monitor this year. We'll see!
@@8_Bit Adrian contacted me about helping. Should be fun. On the 128 the leading nibble shows the bank number. I'm not sure what the right syntax should be on a 64 monitor with an REU, but it seems like it would be good to indicate in some way.
The misaligned byte after $ 3370 could be related that you didn't issue a SEI in the REU transfer code?
If it was a CPU interruption it should be a much bigger interruption than just one byte/cycle, I think. It probably has to do with the SID frequency being $FFFF so once every $10000 cycles (which is the same length of time it takes to transfer the full 64K bank) there will be an extra cycle where the counter doesn't wrap around. So I think it makes sense that there will be a single misaligned byte every time this code is run.
@@8_Bit Good point!
Five minutes into the premiere, cuddling my cat, suddenly she jumps up, starts walking backwards and a minute later her right front paw starts oozing pus. Needless to say I wasn't able to follow the video after that and had to plan a trip to the vet instead. Watching now! :)
Very sorry to hear, I hope she's doing okay now!
@@8_Bit She's fine now, thanks. She didn't let on that she was hurt, it came pretty much out of nowhere... I loved this video, also the info about the NTSC version of Sam's Journey was very interesting... It was nice to see one of your PETs at the beginning of the video. Looking forward to more PET videos! As always, thanks for the great content. Oh, and your songs are the best! :)
is there any source for buying a Super Snapshot v5 ?
JPPBM in Toronto officially sells them, but I haven't heard of anyone managing to buy one from him online in many years. If you're not in Toronto, or can't catch him at VCFMW in Chicago, you're probably not going to get one. I've heard that you can buy an EasyFlash3 and it will emulate a SSv5, so that's worth looking into.
Does to 1750 ONLY work with the C128? If not, can it be modded to work with the C64?
All three units (1700, 1764, 1750 which are 128k, 256k, and 512k respectively) work fine on both the C64 and C128. BUT you need a beefy power supply to use any of them safely on the C64, and that was only included with the 1764 model. So just make sure you have a heavy duty power supply for your C64 and you're fine with the 1750 or any other model.
@@8_Bit what kind of power supply was supplied with it as yhe documentayion doesn't mention one.
@@weedmanwestvancouverbc9266 Here's some good pictures of the 1764 power supply: www.nightfallcrew.com/12/05/2013/commodore-c64-power-supply-for-reu-1764-repaired/
It's basically like a C128 power supply, but with a C64 power connector on it.
Far as I know that 3rd party RAM expander uses less power indeed because it has the RAM on overall fewer chips.
Would be interesting to see if you could reverse engineer the original expanders, using the same core chip but making it with the fewest possible chips. Maybe not worth it in the long run.
I'd definitely like to see a new REU clone being made, and have a lot of ideas for extra features that would make it amazing for making very advanced C64 games.
The CMD cartridge also had RAM technology from a decade later than the 1750.
You're both correct. The clones made by CMD and Software Support International both use 4 256kx4 ZIP chips instead of 16 256kx1 DIPs.
The sticking point to making new clones is economic rather than technical, why would anyone bother when the 1541 Ultimate already includes an REU configurable up to 16 megs?
22:57 what document is that screenshot from?
Whoops, I didn't document that well. I've added it to the description now. It's from the "Commodore 64 1764 Ram Expansion Module User's Guide": archive.org/details/Commodore_64_1764_Ram_Expansion_Module_Users_Guide_1986_Commodore/page/n9/mode/1up
@@8_Bit phew. I kept thinking “I’m pretty sure this is not in the PRG” ;)
Do you own any Amigas?
1.023mhz ntsc cpu speed / 65535 hz noise frequency gives ~16 cpu cycles per noise sample.
So this means on PAL machines you have less cpu cycles per noise sample because of the reduced cpu frequency.
@@Koxi73 Don't think the C64 freq and NTSC freq are related. My PAL C64 also had 1.023 mhz cpu speed
You blank the VIC chip and then immediately re-enable it. The code lacks an empty loop or something else to waste the 65536 cycles the REU chip takes to finish the transfer. Nevertheless I enjoyed the video a lot as I never took the time to learn to program the REU even if I owned one.
The CPU is stopped while the REU does DMA. It’d be awesome if they could share the bus, but they can’t.
@@8_Bit Thanks for the feedback
39:07 I didn't know that RECITER isn't able to pronounce "heart"
Yeah, I thought that was strange too. When I was a kid, I didn't realize how many common words SAM's reciter couldn't correctly pronounce. After all, it didn't have a phonetic dictionary for every English word. With the limited memory and processing power, it, instead, just had a set of standard rules for pronunciation. "Useless" was another hilarious one -- "use E liss!"
Hold on a minute, the sprites are moving and the basic screen is activr. that is true dma then :)
I now realize I didn't make it clear that the REU halts the CPU during DMA. The REU directly accesses C64 RAM, but not simultaneously with the CPU.
Also, during the snowflake routine the REU isn't active at all, the SID random noise output is being read by the CPU. I only used the REU to analyze the behaviour of the SID to better understand how often I can expect a new random value from it at the maximum oscillator frequency.
Thanks for the comments!
@@8_Bit Thanks. I found something in the dieshots and main board schematics.There is a line enabling the address bus drivers of the VIC only on PH0 (clock) high (or was it low).. This signal is closely related to the AEC signal. Following the AEC signal on the main board schematics, AEC meets DMA at an or gate before going to the CPU. Makes sense. The REU and VIC can both stun the cpu :)
The sprites are being moved by an Interrupt routine (IRQ), not by DMA.
@@csbruce "The REU directly accesses C64 RAM" also the REU drives the DMA line if I remember correctly.
an UNOFFICIAL git with the code from these videos is available on GitHub. the link for the Random Code used in this one is github.com/duckyvirus/8bitshowandtell/tree/master/8-Bit%20Show%20And%20Tell%20-%20EP5
Anyone making a modern day 100% REU compatible cartridge?
So could PAL games be even more awesome with a REU?
REU-enabled C64 games would pretty much be equally awesome on NTSC and PAL, I think.
DOOD!
I always wondered why C64 BASIC doesn't let you use hex numbers.
It's because Bill sux.
future1983 “because Jack was too cheap to pay for basic that wasn’t 20 years out of date.”
Fixed that for you.
That BBG cart is similar to EMS in old IBMs... Except considerably worse. An EMS card could have 64K or more per window, 256 bytes is pathetic for 2MB...
It's not much of a limitation on the C64, since the 6510 only has 8-bit index registers anyway. Whether adjusting the RAM window, or the high byte of the pointer you're accessing main RAM with, it's pretty much the same.
60 _fields_ per second, or 30 frames.
The C64 and most other 8-bit computers and game consoles don't output interlaced video; they don't build two interlaced fields and output what we might call 480i at 30 fps, they essentially output the same field at 60 hz which we could call 240p at 60 fps. The video display code and game logic of most games are synced to vblank at 60 Hz on most NTSC computers and consoles; we commonly call this 60 frames per second. Both from the video chip and software perspective there's no distinction of 2 fields per frame.
Too bad the Linux project for commodore didn't go very far. It's pretty cool. TempleOS knock off for commodore, lol
I wonder if with the expanded ram would allow the fully preemptive multitasking AmigaOS to be ported to the Commodore 64.
At 18:05 are they little Donald Trumps?
>Thanks for the video but 40 minutes is too long to watch. And Camera view is always same. Plz make them short and more attractive. Thanks