Nice and informative video! As I'm probably one of the few people left who write C128 'function rom' code still, I also dug a bit more into what a c128 cartridge can and can't do. There exist a few C128 cartridges which are a little bit more complex than just a simple 8/16/32k rom. The first one is warpspeed128, which is the other fastloader cartridge which works for 128 mode. Similar to some C64 fastloaders, it mirrors some of its rom to $de00-deff (or dfff? been a while since I actually looked at it) in io space, which means it doesn't have to 'steal' any ram for the code the io vectors are pointing at (the c128 kernal will ensure the system is in bank 15 before following any of the io vectors, so you need to point those to code which switches to bank 8, calls the proper code there, and returns to bank 15 before giving control back to the kernal or basic). As io space is visible in bank 15, this bit of cartridge rom will be visible in bank 15, but... this does require a little bit of extra hardware to handle the io1/2 signals. The other one is partner128, which is a bit like the sidekick tsr for ms-dos from the 1980s, a calendar/note editor/phone book afair in a cartridge. It has a button which works somewhat similar to a freeze button on some utility cartridges in that it interupts the running program, overlays a menu or builtin app, and lets you return to your running program when done. It uses a pretty convoluted way to handle interupting the running program, which involves a cable running from the cartridge to joystick port 2. How it exactly works is worthy of a video or long article, but an important take-away is that in 128 mode, there is no 'ultimax' mode, and that means you cannot make a reliable 'freeze' mode. Partner128 works pretty well in combination with most text mode productivity software on the 128 which runs on the 80 column display, but forget about geos128 for example, it will disable the 'freeze' trick of the partner128 cartridge. It is also special in having a bit of ram (used to backup some system ram it uses when in 'freeze' mode) And it also has some rom mirrored in io12 space (copy of rom at I think $9e00) Dumping the rom of those is similar to what you show here (both are 16k roms iirc), but.. like with 64 cartridges, an emulator would need to know about the extra hardware. In theory, c128 .crt files are possible, the generic (type 0) cartridge is defined even, but doesn't provide any advantages over using a .bin file. A type 1 is also defined for the warpspeed128 type cartridge, but for all I know neither type 0 or 1 is supported by vice (the crt converter should recognize them tho). The Ultimate II+ cartridge does support type 0 and type 1 (with a bunch of sub variants) c128 .crt files, so... with one and a real c128, you could emulate the warpspeed128 cart. The appropriate crt files are on csdb, and I think also in assembly64 Emulating partner128... is a bit more difficult, and probably would require modifying the code somewhat to get rid of that control port 2 cable insanity. No cartridge type was defined for it so far, tho type 1 subtype 2 (c128 device manager) has a lot in common with it and is more or less a superset (it allows upto 1mb of rom with internal rom banking, but... obviously lacks the silly control port cable) Ah yes... something about the 'autostart' byte in the function rom header.... mach128, and many other function roms indeed use $ff, which will cause the cartridge to only get started during the 'phoenix' stage of startup, that is, after basic 7 completed initializing, and just before boot from disk is attempted. As you indicated, one can make a rom which doesn't autostart. But there is also another option, you can make a function rom which gets autostarted very early on, before kernal does any initialization (beyond checking for function roms). Additionally, if function roms are written properly, you can have an internal and external function rom coexist and work together. Despite the lack of a ultimax like trick (which would allow for a 'real' freeze mode), the way function roms work is quite nice and flexible.
Thank you for the compliment, and all of the information! I'm still very much exploring the C128, as I never actually owned one back in the day. That's excellent that you're still actively developing for it. Most of what I know about Int./Ext. ROMs is via the C128 Programmer's Guide. CARTCONV does create C128 generic ("External ROM") cartridges, as well as WarpSpeed. I similarly have no idea what would be gained by a generic cartridge -- or if VICE supports either -- but I may play around with that at some point. A MACH128 (albeit a newer version than the one I just dumped) is what I'm presently going with for my actual C128. For cartridges that have extra special hardware in them, it seems VICE x128 prefers to implement those individually in settings under "Cartridges". It's funny that you mention how Int/Ext function ROMs can co-exist; I'm modifying an Internal Function ROM for my own C128 that gets along with MACH128 quite nicely. Ideally, that will be showing up in a future video! -- JC
@@BasicBitesCA is there a rom dump available of the latest mach128 version you are aware of? I'd like to include it in my package of C128 crt files for the Ultimate II+.
Excellent and informative as always. It is always a good day on TH-cam when there is a new Basic Bites episode. One thought: Could you use the BSAVE command in BASIC to save out the file instead? They are probably the same I guess. Keep up the good work.
Thank you for the comment, as always! I'm glad you're enjoying the episodes. You guessed correctly; BSAVE demonstrated the same issue saving from Bank 8. Of course you could just as well use BSAVE *after* transferring the data from ROM to RAM, but at that point it's easier to save directly from the ML Monitor. -- JC
Nice Video as I have done many and you simplified a lot of functions which I wanted to see if you did and you did it just as I found! Thanks and I see you split them in one session which is cool! Something I like as I learn something new everyday and today you showed me one! I also never used CartConv so this is a time saver as I do them by hand! Good job!
It's very interesting and informative. Can we do the same procedure with the Epyx Fastload cartridge with a C64? The monitor is included. (maybe a topic for a future video? 😀)
Thank you! Dumping cartridges on a C64 is not as straightforward as a C128. I might very well make a video on it if I ever have occasion to do it, but most C64 cartridges have already been dumped. For more information, I would highly recommend doing an Internet search for Markus Brenner's "Dumping Cartridges on the Commodore 64" page, which also contains links to a number of C64 cartridge-dumping tools to ease the process. -- JC
Are you sure that a compare command like "C 8000 9FFF 88000" (or the similar T command) do actually include the byte at 9FFF? It is very common to specify the end of a range by the first byte that isn't included in it (like with the S command). If in doubt, I would Transfer or Compare a byte more, just to be sure.
A fair question, but I was not in doubt! 😉 The (C)ompare and (T)ransfer commands in the C128 Monitor are indeed inclusive of the ending byte given. The fact that the (S)ave command is exclusive of the final byte and requires ending address + 1 is inconsistent within the monitor, but does align with how BSAVE works in BASIC. -- JC
👍Great Video👍- All the switch does is to select whether the last address-line A13 (or pin 26) on a 27C128 EPROM is set to low or high (0/1). Thereby effectively dividing the 16KB EPROM into 2 banks of 8KB. Literally selecting if the MACH-5 half or the MACH-128 half is visible to the system at ROM address $8000-$9FFF. No additional logical 74LSxxx IC based circuits or other fancy electronics. Just a simply brute force switch... and why would you need more? ❤ Try looking up the datasheet for a 27C128 EPROM, you will see what I mean... pin 26 😉 - What I am really curious about is how well the MACH-5 / MACH-128 will work with a Pi1541. Because I have some PCBs designed to make Epyx Fast Loader and Pi-Zero Pi1541 combo cartridges. It could be fun to see if they would work with the MACH-5 / MACH-128 by adding a similar switch.
Thank you for the compliment, and the information! Any 1541 speeder cartridge will (or at least should) work with a Pi1541, since it is doing full emulation of a real disk drive. However, my hunch is that combining more ROMs onto the Pi1541/Fastload combo cartridge itself could be complicated, since the original cartridges may differ in what lines they're pulling low, or whether they're using IO1/IO2. The great thing about the combo cartridge is that you can power it off the Expansion Port when you want an Epyx Fastload, and switch to external USB power when you want to use a different cartridge. I almost never had mine plugged into the port, and ultimately switched away from using it for reasons discussed in my video on upgrading my Pi1541 to 3A+. -- JC
@@BasicBitesCA I guess I'm more interested in the electronics side of the retros. Because I seem to have fun fixing them and figuring this kind of stuff out. So, what traces I have to cut and how I need to rewire the PCBs to get it working, that is the fun part... I'll figure it out, eventually. I already have various storage/loading solutions, so it is not like I really need these cartridges. I just thought it would be neat to have a Pi1541 cartridge (single unit) solution with a speed-loader that works on an C128 in both 64 and 128 mode and if possible with the same DOS-wedge Basic commands. Power shouldn't be a problem because of the C128's beefier PSU. I have also build several Pi1541s with Pi-Zeros, Pi2s and Pi3s (A+/B/B+)... again (same pattern) mostly for some of my friends. I like the Pi-Zero version for its compactness and low power consumption. What I don't like about the Pi-Zero Pi1541 PCBs, are their lack of the 7406 hex-inverter for multiple drive support. But that should be rectifiable with the more powerful "new" Pi-Zero 2... that is of course, if we could get bloody hold of some, right?
@@Zhixalom It should be quite possible to redesign the bottom half of a Pi1541/Fastload combo cartridge PCB to make it into any cartridge you want. I believe the only signal that is communicated between the "cartridge" and "Pi1541" halves is the 5V power. I thought you meant you wanted to add MACH128/MACH5 and other ROMs in addition to the existing Epyx Fastload, which could become complicated. As for Pi1541: actually you can build an "Option B" hardware hat for *any* model of Pi, but very few makers have been inclined to do so for the Pi Zero. CBMRETRO recently released a new version of their "Vertical Pi1541 Hat for Raspberry Pi Zero" that has the hex inverter. It's the only such model presently on the market that I'm aware of. Had it been available last year, I wouldn't have been forced to buy a Pi 3A+ to get an Option B hat. - JC
@@BasicBitesCA Yeah, using a 27C512 EPROM to get 4 banks of 8K is the idea... and obviously the ideal PCB would be something like the "8K Cartridge V2" PCB from TFW8b (or an equivalent) with the Pi1541 on top. But I don't have any of those and I've not gotten as far as designing my own PCBs yet. I had also noticed that all the Pi-Zero gets from the cartridge port is GND and 5V. - But just off the top of my head; I need the ROM_L to be set at all times (which I'd imagine it already would be), then I need to toggle the EXROM to switch between C64 and C128 cartridge mode, and then I need to set the A13 and A14 address lines to 00, 01, 10 or 11 in order to select between the 4 banks. I may be wrong, but it really doesn't seem that complicated to me... nothing that a 4 position 2x5 pin sliding-switch (which I have) couldn't manage, maybe with a 74xx IC, like a hex inverter or a quad NAND, or maybe even just some small signal schottky diodes couldn't handle... and even just being a bit smart with the order in which "you" stack the 4 ROMs inside the 27C512 can go a long way in terms of simplifying things even further.
@@Zhixalom Hi, I'm the developer of Pi1541 and would love to know how you get on if you do make this cartridge. Please let me know, if you get it working, thanks.
I tried setting the MACH128-1B.bin file you shared as a External Function ROM in VICE (with the type set to ROM) and it doesn't appear after reseting. I get the standard 128 boot screen. What am I missing?
Good question! I've just re-tried the file, and it works perfectly for me in VICE 3.6.1 (64bit GTK3) on Windows 10. I get "MACH-128 V.1B WITH WARP DRIVE!" on start-up. Just as you've mentioned, it's an External Function ROM with type set to "ROM", and I haven't done anything special that I'm aware of. -- JC
I go to "Settings" -> "C128 settings" -> "Funtion ROM" (tab), select "External Function ROM type" as "ROM', choose the MACH128-1B.bin file, click OK and do a reset (hard or soft) afterwards... it works just fine. I get the green C128 screen with the "MACH-128 V.1B WITH WARP DRIVE!" added. - So, I'm not quite sure what you are doing wrong 🤔
"...In order to get the files off the disk." Why would we want to do that? Shouldn't just getting them _from_ the disk but leaving them on it be enough?
At 20:18 I noticed that when extracting files from a .d64 image using VICE's c1541.exe command line app, it extracts all the files into the "BIN" folder which contains a bunch of system files. While not a problem for a few files or listing them by a known name (ex. dir m*.*), finding multiple files is more difficult. Here's a solution for extracting files to a specific folder. First create a new folder for example c:\C64extract, and copy or move the .d64 file there. Open a CMD prompt in the c:\C64extract folder (or CD there), then enter the command line below. Substitute the where your VICE folder is located. C:\\BIN\C1541.exe -extract Now you should have all the extracted files from the .d64 image in the c:\C64extract folder for easy finding without a bunch of other system files. :)
Never felt more validated than seeing that two byte difference and then you calling it right out.
LOL! You must be one of those old-school programmers I was talking about. 😎 -- JC
Nice and informative video!
As I'm probably one of the few people left who write C128 'function rom' code still, I also dug a bit more into what a c128 cartridge can and can't do.
There exist a few C128 cartridges which are a little bit more complex than just a simple 8/16/32k rom.
The first one is warpspeed128, which is the other fastloader cartridge which works for 128 mode. Similar to some C64 fastloaders, it mirrors some of its rom to $de00-deff (or dfff? been a while since I actually looked at it) in io space, which means it doesn't have to 'steal' any ram for the code the io vectors are pointing at (the c128 kernal will ensure the system is in bank 15 before following any of the io vectors, so you need to point those to code which switches to bank 8, calls the proper code there, and returns to bank 15 before giving control back to the kernal or basic). As io space is visible in bank 15, this bit of cartridge rom will be visible in bank 15, but... this does require a little bit of extra hardware to handle the io1/2 signals.
The other one is partner128, which is a bit like the sidekick tsr for ms-dos from the 1980s, a calendar/note editor/phone book afair in a cartridge. It has a button which works somewhat similar to a freeze button on some utility cartridges in that it interupts the running program, overlays a menu or builtin app, and lets you return to your running program when done. It uses a pretty convoluted way to handle interupting the running program, which involves a cable running from the cartridge to joystick port 2. How it exactly works is worthy of a video or long article, but an important take-away is that in 128 mode, there is no 'ultimax' mode, and that means you cannot make a reliable 'freeze' mode. Partner128 works pretty well in combination with most text mode productivity software on the 128 which runs on the 80 column display, but forget about geos128 for example, it will disable the 'freeze' trick of the partner128 cartridge.
It is also special in having a bit of ram (used to backup some system ram it uses when in 'freeze' mode)
And it also has some rom mirrored in io12 space (copy of rom at I think $9e00)
Dumping the rom of those is similar to what you show here (both are 16k roms iirc), but.. like with 64 cartridges, an emulator would need to know about the extra hardware.
In theory, c128 .crt files are possible, the generic (type 0) cartridge is defined even, but doesn't provide any advantages over using a .bin file. A type 1 is also defined for the warpspeed128 type cartridge, but for all I know neither type 0 or 1 is supported by vice (the crt converter should recognize them tho).
The Ultimate II+ cartridge does support type 0 and type 1 (with a bunch of sub variants) c128 .crt files, so... with one and a real c128, you could emulate the warpspeed128 cart. The appropriate crt files are on csdb, and I think also in assembly64
Emulating partner128... is a bit more difficult, and probably would require modifying the code somewhat to get rid of that control port 2 cable insanity. No cartridge type was defined for it so far, tho type 1 subtype 2 (c128 device manager) has a lot in common with it and is more or less a superset (it allows upto 1mb of rom with internal rom banking, but... obviously lacks the silly control port cable)
Ah yes... something about the 'autostart' byte in the function rom header....
mach128, and many other function roms indeed use $ff, which will cause the cartridge to only get started during the 'phoenix' stage of startup, that is, after basic 7 completed initializing, and just before boot from disk is attempted.
As you indicated, one can make a rom which doesn't autostart. But there is also another option, you can make a function rom which gets autostarted very early on, before kernal does any initialization (beyond checking for function roms). Additionally, if function roms are written properly, you can have an internal and external function rom coexist and work together.
Despite the lack of a ultimax like trick (which would allow for a 'real' freeze mode), the way function roms work is quite nice and flexible.
Thank you for the compliment, and all of the information! I'm still very much exploring the C128, as I never actually owned one back in the day. That's excellent that you're still actively developing for it. Most of what I know about Int./Ext. ROMs is via the C128 Programmer's Guide. CARTCONV does create C128 generic ("External ROM") cartridges, as well as WarpSpeed. I similarly have no idea what would be gained by a generic cartridge -- or if VICE supports either -- but I may play around with that at some point. A MACH128 (albeit a newer version than the one I just dumped) is what I'm presently going with for my actual C128. For cartridges that have extra special hardware in them, it seems VICE x128 prefers to implement those individually in settings under "Cartridges". It's funny that you mention how Int/Ext function ROMs can co-exist; I'm modifying an Internal Function ROM for my own C128 that gets along with MACH128 quite nicely. Ideally, that will be showing up in a future video! -- JC
@@BasicBitesCA is there a rom dump available of the latest mach128 version you are aware of? I'd like to include it in my package of C128 crt files for the Ultimate II+.
Excellent and informative as always. It is always a good day on TH-cam when there is a new Basic Bites episode. One thought: Could you use the BSAVE command in BASIC to save out the file instead? They are probably the same I guess. Keep up the good work.
Thank you for the comment, as always! I'm glad you're enjoying the episodes. You guessed correctly; BSAVE demonstrated the same issue saving from Bank 8. Of course you could just as well use BSAVE *after* transferring the data from ROM to RAM, but at that point it's easier to save directly from the ML Monitor. -- JC
Nice Video as I have done many and you simplified a lot of functions which I wanted to see if you did and you did it just as I found! Thanks and I see you split them in one session which is cool! Something I like as I learn something new everyday and today you showed me one!
I also never used CartConv so this is a time saver as I do them by hand! Good job!
Thank you for the praise! Glad to hear that I've been able to save you some time with CARTCONV in the future. -- JC
It's very interesting and informative. Can we do the same procedure with the Epyx Fastload cartridge with a C64? The monitor is included. (maybe a topic for a future video? 😀)
Thank you! Dumping cartridges on a C64 is not as straightforward as a C128. I might very well make a video on it if I ever have occasion to do it, but most C64 cartridges have already been dumped. For more information, I would highly recommend doing an Internet search for Markus Brenner's "Dumping Cartridges on the Commodore 64" page, which also contains links to a number of C64 cartridge-dumping tools to ease the process. -- JC
thanks for this nice infos. i did not kow that there are catridges for c128 mode.
Are you sure that a compare command like "C 8000 9FFF 88000" (or the similar T command) do actually include the byte at 9FFF? It is very common to specify the end of a range by the first byte that isn't included in it (like with the S command). If in doubt, I would Transfer or Compare a byte more, just to be sure.
A fair question, but I was not in doubt! 😉 The (C)ompare and (T)ransfer commands in the C128 Monitor are indeed inclusive of the ending byte given. The fact that the (S)ave command is exclusive of the final byte and requires ending address + 1 is inconsistent within the monitor, but does align with how BSAVE works in BASIC. -- JC
"If you've ever used... these are the exact same thing."
I bet they are even if we _haven't_ used that command.
👍Great Video👍- All the switch does is to select whether the last address-line A13 (or pin 26) on a 27C128 EPROM is set to low or high (0/1). Thereby effectively dividing the 16KB EPROM into 2 banks of 8KB. Literally selecting if the MACH-5 half or the MACH-128 half is visible to the system at ROM address $8000-$9FFF. No additional logical 74LSxxx IC based circuits or other fancy electronics. Just a simply brute force switch... and why would you need more? ❤
Try looking up the datasheet for a 27C128 EPROM, you will see what I mean... pin 26 😉
- What I am really curious about is how well the MACH-5 / MACH-128 will work with a Pi1541. Because I have some PCBs designed to make Epyx Fast Loader and Pi-Zero Pi1541 combo cartridges. It could be fun to see if they would work with the MACH-5 / MACH-128 by adding a similar switch.
Thank you for the compliment, and the information! Any 1541 speeder cartridge will (or at least should) work with a Pi1541, since it is doing full emulation of a real disk drive. However, my hunch is that combining more ROMs onto the Pi1541/Fastload combo cartridge itself could be complicated, since the original cartridges may differ in what lines they're pulling low, or whether they're using IO1/IO2. The great thing about the combo cartridge is that you can power it off the Expansion Port when you want an Epyx Fastload, and switch to external USB power when you want to use a different cartridge. I almost never had mine plugged into the port, and ultimately switched away from using it for reasons discussed in my video on upgrading my Pi1541 to 3A+. -- JC
@@BasicBitesCA I guess I'm more interested in the electronics side of the retros. Because I seem to have fun fixing them and figuring this kind of stuff out. So, what traces I have to cut and how I need to rewire the PCBs to get it working, that is the fun part... I'll figure it out, eventually.
I already have various storage/loading solutions, so it is not like I really need these cartridges. I just thought it would be neat to have a Pi1541 cartridge (single unit) solution with a speed-loader that works on an C128 in both 64 and 128 mode and if possible with the same DOS-wedge Basic commands. Power shouldn't be a problem because of the C128's beefier PSU.
I have also build several Pi1541s with Pi-Zeros, Pi2s and Pi3s (A+/B/B+)... again (same pattern) mostly for some of my friends. I like the Pi-Zero version for its compactness and low power consumption. What I don't like about the Pi-Zero Pi1541 PCBs, are their lack of the 7406 hex-inverter for multiple drive support. But that should be rectifiable with the more powerful "new" Pi-Zero 2... that is of course, if we could get bloody hold of some, right?
@@Zhixalom It should be quite possible to redesign the bottom half of a Pi1541/Fastload combo cartridge PCB to make it into any cartridge you want. I believe the only signal that is communicated between the "cartridge" and "Pi1541" halves is the 5V power. I thought you meant you wanted to add MACH128/MACH5 and other ROMs in addition to the existing Epyx Fastload, which could become complicated.
As for Pi1541: actually you can build an "Option B" hardware hat for *any* model of Pi, but very few makers have been inclined to do so for the Pi Zero. CBMRETRO recently released a new version of their "Vertical Pi1541 Hat for Raspberry Pi Zero" that has the hex inverter. It's the only such model presently on the market that I'm aware of. Had it been available last year, I wouldn't have been forced to buy a Pi 3A+ to get an Option B hat.
- JC
@@BasicBitesCA Yeah, using a 27C512 EPROM to get 4 banks of 8K is the idea... and obviously the ideal PCB would be something like the "8K Cartridge V2" PCB from TFW8b (or an equivalent) with the Pi1541 on top. But I don't have any of those and I've not gotten as far as designing my own PCBs yet. I had also noticed that all the Pi-Zero gets from the cartridge port is GND and 5V.
- But just off the top of my head; I need the ROM_L to be set at all times (which I'd imagine it already would be), then I need to toggle the EXROM to switch between C64 and C128 cartridge mode, and then I need to set the A13 and A14 address lines to 00, 01, 10 or 11 in order to select between the 4 banks.
I may be wrong, but it really doesn't seem that complicated to me... nothing that a 4 position 2x5 pin sliding-switch (which I have) couldn't manage, maybe with a 74xx IC, like a hex inverter or a quad NAND, or maybe even just some small signal schottky diodes couldn't handle... and even just being a bit smart with the order in which "you" stack the 4 ROMs inside the 27C512 can go a long way in terms of simplifying things even further.
@@Zhixalom Hi, I'm the developer of Pi1541 and would love to know how you get on if you do make this cartridge. Please let me know, if you get it working, thanks.
I tried setting the MACH128-1B.bin file you shared as a External Function ROM in VICE (with the type set to ROM) and it doesn't appear after reseting. I get the standard 128 boot screen. What am I missing?
Good question! I've just re-tried the file, and it works perfectly for me in VICE 3.6.1 (64bit GTK3) on Windows 10. I get "MACH-128 V.1B WITH WARP DRIVE!" on start-up. Just as you've mentioned, it's an External Function ROM with type set to "ROM", and I haven't done anything special that I'm aware of. -- JC
I go to "Settings" -> "C128 settings" -> "Funtion ROM" (tab), select "External Function ROM type" as "ROM', choose the MACH128-1B.bin file, click OK and do a reset (hard or soft) afterwards... it works just fine. I get the green C128 screen with the "MACH-128 V.1B WITH WARP DRIVE!" added.
- So, I'm not quite sure what you are doing wrong 🤔
I just checked... and I am only using WinVICE version 3.1 on this PC (not the latest v3.6.1)
"...In order to get the files off the disk."
Why would we want to do that? Shouldn't just getting them _from_ the disk but leaving them on it be enough?
"...Using no special equipment really other than the computer itself."
So using no special equipment... PERIOD.
At 20:18 I noticed that when extracting files from a .d64 image using VICE's c1541.exe command line app, it extracts all the files into the "BIN" folder which contains a bunch of system files. While not a problem for a few files or listing them by a known name (ex. dir m*.*), finding multiple files is more difficult.
Here's a solution for extracting files to a specific folder.
First create a new folder for example c:\C64extract, and copy or move the .d64 file there.
Open a CMD prompt in the c:\C64extract folder (or CD there), then enter the command line below.
Substitute the where your VICE folder is located.
C:\\BIN\C1541.exe -extract
Now you should have all the extracted files from the .d64 image in the c:\C64extract folder for easy finding without a bunch of other system files. :)
That's a good tip. I believe I've generally just sorted the BIN folder by date after extracting a D64 to find the files. -- JC
@@BasicBitesCA- Ya, sorting it by date works too, though you'd likely want to move it to an empty folder to separate the files.