Denial

I'm new to the VIC-20 (a vet on the C64) but I'm not sure which expansion product to get..

Utimem or Final Expansion?

-8b

The UltiMem has much more RAM and ROM space and is more configurable for those functions. The FE3 has RAM and ROM as well as a built-in SD2IEC device, SJLoad fast loader, and battery-backed up clock.

I know you cannot run the VIC-20 version of Doom on the FE3 but I think you can with the UltiMem.

To really get an idea of which is best for you, you might want to look at the UltiMem WIKI and the great user manual that another Denial member made for the FE3.

UltiMem WIKI: http://sleepingelephant.com/denial/wiki ... le=UltiMem

FE3 Manual: https://eden.mose.org.uk/download/FE3%2 ... 0Guide.pdf

They are both great cartridges so you won't go wrong no matter which one you buy.

Heather

I have both carts and I would choose the Ultimem.

The Ultimem is more configurable and then more powerful than the FE3
The SuperRAM mode of the FE3 is very weak compared to the memory management of the Ultimem.
the FE3 is buggy, it has crossovers and for example can't run DOOM which needs a 35K memory expansion.
(The Ultimem can run DOOM).

and as a developer, I won't support the FE3 in the future, my new VIC project : International Karate http://sleepingelephant.com/ipw-web/bul ... =10&t=8698 requiring an Ultimem is impossible to make for the Final Expansion 3.

At first it is not very easy to get started with the Ultimem; you have to build the image file with all the programs, cart images you want to flash to its flash rom, fortunately there are docs from Jim Brain and Marko Makela...

I beg to differ.

First of all, FE3 predates Ultimem by quite a few years (2009 vs. 2015/16), so it's no wonders a few weaknesses of FE3 had been ironed out with Ultimem. The general set-up though shows no big differences: both feature a large, banked SRAM and likewise, Flash-EPROM. Ultimem contains *no* SD2IEC, so that has to be attached as extra hardware.

majikeyric wrote:the FE3 is buggy, it has crossovers and for example can't run DOOM which needs a 35K memory expansion.

The RAM crossover issues show on NTSC, but only a few PAL machines. You *can* run Doom with FE3 on a PAL VIC-20, unless you happen to stumble upon a problematic VIC-20.

There had been a lively discussion about that issue, and in principle it should be possible to device an improved set of logic equations for the CPLD of FE3 so it works with +35K on all VIC-20, regardless whether PAL or NTSC. Unfortunately, that discussion wasn't followed through by some work on it. *)

The SuperRAM mode of the FE3 is very weak compared to the memory management of the Ultimem.

This is true and also had been pointed out several times. However, the SuperRAM mode has been put to good use by the FE3 RAM Disk driver from Kananga. It's not his fault, when other people don't get to grips with it.

FE3 came with a functioning firmware right from the start, with a built-in menu to select RAM configurations, flash cartridge images into slots of the Flash EPROM, etc. From what I saw, Ultimem was first released without any hint of standard firmware, which urged people write their own firmware just to get standard RAM configurations working. Those several firmwares are supposedly not compatible with each other, and most likely do an unfriendly take-over in case a new main application is used with Ultimem. It's that chaos, that made me actually refrain from buying an Ultimem, given that (as I wrote above) it is only an improvement over FE3 in size, but - ultimately! - not function (and misses a built-in SD2IEC!).

I own a FE3 - in the end however, I ended up using the combination Mega-Cart and C64SD Inf. - currently, that setup works with nearly all software around for the VIC-20. The few exceptions that rely on RAM banking are only that: a few and in-between. In that case, I might consider putting the FE3 back in service.

What I really expected from a new RAM/Flash/Drive-cartridge for the VIC-20 was not only increased RAM and Flash space, together with a sanitized register setup, but also much improved drive I/O in excess of 100 KB/s with dynamically constructed PIO transfer routines like it was planned with GCart 2011. Sadly, that project never seemed to take off.

Greetings,

Michael


*) there's actually another way to avoid the RAM access problem: by installing the 3K RAM internally to the VIC-20 as I did with my VFLI mod (parts 1 and 2a..c - part 3 with the colour RAM replacement wouldn't be necessary for this feat). Then, all accesses in $0400..$0FFF are served by the internal RAM and don't appear anymore on the expansion bus - thus there can't be anymore any crossovers between RAMx and BLKx.

I use the MegaCart + SD2IEC combination as well and this just works fantastic. Especially having SJLOAD hidden in the IO2/3-area from startup on MegaCart works great in combination with the SD-card. On the question what to get NOW I would suggest the Penultimate Cart. It has the full 35K-expansion without crosstalk and also 40 ROM-images on it. Its drawbacks are that there are not *all* available ROM-carts on it and that it does not have the SJLOAD in the IO-area (in fact it does not feature the IO-area at all). The big plus is that it is available ready-built including a case!

I have the UltiMem as well and really love what it *could* do, but sadly there is no really good firmware for it and it comes without a case. Theoretically most of the MegaCart-features could be handled by a special UltiMem-firmware I guess. It's just that nobody has done it.

As a programmer working on a couple of big projects for the VIC-20, I'd error on the side of the Ultimem. Having the freedom to create your own firmware is a big plus to me. I didn't buy my cart to play pre-configured cart games, but to get an ultra-powerful memory expansion.

You don't even need to program firmware to use it. I boot it straight to basic, which comes up unexpanded. I then have a very small program I wrote that configures the Ultimem to any of it's memory configurations, selectable by Function Key. It configures the Ultimem's memory and then reboots to the new configuration. No muss, no fuss. And I'm not "stuck" with a firmware I may want to overwrite with something more useful.

What's more useful? How about games and other software that actually use a VIC-20 to it's fullest. I'm working on two projects that would be impossible without banking RAM/ROM. I know initially this will inhibit the number of people playing the software, but I believe that sales of Ultimem will increase as new titles come out.

You can think of Ultimem as the VIC-20 equivalent of EasyFlash for the C64. The main difference is that the EasyFlash ecosystem is more mature. That will change with Ultimem over time.

plbyrd wrote: I'm working on two projects that would be impossible without banking RAM/ROM.

How can you be sure about that?

Given a much more faster file I/O from SD card (as I wrote, in excess of 100 KB/s), a full RAM expansion, and a little thoughtful working set tuning should be able to give a comparable performance to a banking RAM/ROM solution. *) With the difference, that there exists a standard file access protocol, which also benefits existing games and applications, and especially those which aren't just one-filers. And not only newly-written software, which then is tied to a specific hardware.

Programs, that fall into this category have been written already. Take for example the two Bible series (Gospels, Acts, Revelation and Pentateuch) - their data volume approaches 800 KB each **) and they come as *.d81 disk image. They work with a standard +24K RAM expansion and a 1581, even if a little bit slow. With a JiffyDOS-enabled drive and computer, new chapters and other data are loaded fairly fast. They'd *fly* with my aforementioned solution!

Unfortunately, the current sd2iec firmware still doesn't understand 1581 partitions, which we - orion70 and me - used to keep the main directory small. For this reason, the *.d81 files don't work on SD2IECs at the moment.

You can think of Ultimem as the VIC-20 equivalent of EasyFlash for the C64.

I don't buy this. The EF can also replace the C64 KERNAL, something no external cartridge on the VIC-20 will ever be capable of.

I stick by my premise: Ultimem is an improvement compared to FE3 but it missed out on an opportunity to make it really great. Even one, two or a few more Ultimem-specific programs won't persuade me otherwise.



*) I can think of situations, where a banking mechanism is still faster in practice, but this involves a lot of streamlined code, which needs to be remapped extremely often. Possibly a current WIP here indeed falls into that category. majikeyric?

**) actually, Pentateuch has more than 800 KB of text. The chapters are compressed on disk, and loaded to RAM using a streaming decompressor.

Mike wrote:

plbyrd wrote: I'm working on two projects that would be impossible without banking RAM/ROM.

How can you be sure about that?

Given a much more faster file I/O from SD card (as I wrote, in excess of 100 KB/s), a full RAM expansion, and a little thoughtful working set tuning should be able to give a comparable performance to a banking RAM/ROM solution. *) With the difference, that there exists a standard file access protocol, which also benefits existing games and applications, and especially those which aren't just one-filers. And not only newly-written software, which then is tied to a specific hardware.

Well, the two projects are an OS and a very large game. The OS needs to not only be fast, but agile. Even on a solid-state drive solution, you still need to parse a (potentially large) directory of files to find the file needed.

The game will have a lot of graphics data... a lot, and switching between screens will be a very common occurance (maps have two zoom levels, each location has a screen, and then there's the help system...). I know for a fact it wouldn't fit on a single 1541 side, even if I was inclined to make the users consume that pain (even with JiffyDOS, there'd be constant disk access).

So the then we get into the crux of the matter. Every VIC20 has an expansion port. Outside the US many VIC20 owners only have a tape drive. Hardly any VIC20 owners are going to have a 1581. That leaves SD2IEC solutions, and even they cannot keep up with a banking cart.

So, you can make the users buy a 1581 (expensive and slow), an SD2IEC (not as expensive, but not quite fast enough either), or a single, reusable cart who's price is close enough to the SD2IEC as to be a negligable difference.

You can think of Ultimem as the VIC-20 equivalent of EasyFlash for the C64.

I don't buy this. The EF can also replace the C64 KERNAL, something no external cartridge on the VIC-20 will ever be capable of.

EF and EF3 are two different things. Ultimem is analogous to EF. I have had several standard EF carts and a couple of EF3 carts. I do not deny that EF3 is superior, but a standard EF cart is essentially an Ultimem with a decent ecosystem around it.

*) I can think of situations, where a banking mechanism is still faster in practice, but this involves a lot of streamlined code, which needs to be remapped extremely often. Possibly a current WIP here indeed falls into that category. majikeyric?

**) actually, Pentateuch has more than 800 KB of text. The chapters are compressed on disk, and loaded to RAM using a streaming decompressor.

I don't see where streamlined code is necessary for banking. As a matter of fact, I see the opposite. You simply set a register to switch the bank. To load data from a disk requires kernal calls to SETLFS, SETNAM, CHKIN, OPEN, etc. Even using LOAD, you still have to use STLFS and SETNAM.

Plus, with the flash based nature of Ultimem, you can save directly to flash within the game itself without writing state to disk. Want self-modifying code like Wasteland? It's near instantaneous with Ultimem. You can even leave a copy of the unmolested game in the cart to allow infinite replayability. Ultimem is big enough to handle practically anything I could dream of throwing at it, and fast enough to make it seamless.

plbyrd wrote:So the then we get into the crux of the matter. Every VIC20 has an expansion port. Outside the US many VIC20 owners only have a tape drive.

Who told you that nonsense?

You can count on that every VIC-20 user actively pursuing this hobby has a feasible mass storage solution at his hands.

If someone complains being stuck with tape, sorry. He's just not in the 'club', so to speak. Even having the biggest (RAM) cartridge in the back of the VIC-20 isn't going to help to get anything big done, given the transfer rates of tape.

Hardly any VIC20 owners are going to have a 1581.

People went beyond the VIC-20 at that time, with a C64, C128 and - possibly! - a 1581. As it happens, the 1581 *works* with their VIC-20, that people just might have kept. For whatever reason. It was, and still is, a working solution for big applications and games, and Ghislain is going that way with Realms of Quest 5.

That leaves SD2IEC solutions, and even they cannot keep up with a banking cart.

SD2IECs are mass storage devices. Their speed is limited by the IEC bus, even given the use of JiffyDOS or SJLOAD. But they have the charme they work with nearly all existing games, applications, tools and other programs; either by accessing the native partition, file-based, or working with(in) *.d64 or *.d81 disk images.

A program using a banked RAM expansion is *tied* to that hardware. You can't use it without exactly that cartridge.

I was proposing a solution for big applications, that would be much faster than (even JD-enabled) SD2IEC drives, and benefit nearly all programs for the VIC-20. Not only a few selected (which, incidently, still have to be written). Granted, its speed still would be slower than RAM/ROM banking - but you'd have to deliver a program that *exceptionally* benefits from banking to make it significantly faster than my more conventional approach of replacing RAM data with an overlay method (given *fast* file I/O, once again, in excess of 100 KB/s! That's at least one tenth the speed the 6502 is going to access the memory, you know.)

I don't see where streamlined code is necessary for banking. As a matter of fact, I see the opposite. You simply set a register to switch the bank.

I was not talking about the code that does the banking.

I was talking about the data and code that is banked. Unless the 6502 uses the banked data/code like a 'data pump' (i.e. unrolled loops, compiled sprites, *extremely* *big* tables) there won't be any noticeable difference in speed between banking and file access.

Just make a guess on how often data needs to be exchanged, regardless whether by banking or file I/O, and set the necessary time into proportion with the total time spent within the main program: if file I/O needs 10% of the time, and the rest 90%, even near-instantaneous data refresh by banking will increase the execution speed by only 11%!

To load data from a disk requires kernal calls to SETLFS, SETNAM, CHKIN, OPEN, etc. Even using LOAD, you still have to use STLFS and SETNAM.

So what? These calls are there, they're *standard*, and they *work*. I use them routinely in my programs. And those programs are not only just some toys - given the scope they work within: no VIC-20 program today could seriously want to better programs running on PCs. But some of my programs at least could make the user forget sometimes they're indeed using them on a VIC-20.

Once again, even if banking is simply done using one or a few register writes, there's simply no standard across different RAM cartridges that provide banking, and never could one expect that ever to happen. In that case, these banked RAM cartridges would have to be clones of an an agreed-upon near-perfect design. Didn't happen in those times, in the near past and isn't going to happen anytime soon.

Plus, with the flash based nature of Ultimem, you can save directly to flash within the game itself without writing state to disk.

The ability or necessity to save state gives no argument for or against file I/O. I have no problems doing this. In case of (file) editors, it's their very function.

I don't buy this. The EF can also replace the C64 KERNAL, something no external cartridge on the VIC-20 will ever be capable of.

nope the EF is a simple banked cartridge with 1MB ROM. the EF3 can replace the kernal as an extra feature, however that is something none of the easyflash releases makes use of (and shouldnt make use of so it still works on regular easyflash, and the other platforms that support the format, like the 1541U and the chameleon)

My post got eaten again.

groepaz wrote:[...] the EF3 can replace the kernal as an extra feature, however that is something none of the easyflash releases makes use of [...]

My bad. I was referring to "EF" as the latest incarnation of this cartridge series as known to me. Namely the EF3 with said feature.

And agreed, a KERNAL replacement should only happen at the user's choice, not because a program or game demands a certain KERNAL other than standard. Where would we be then?

plbyrd wrote:My post got eaten again.

This time it wasn't me, honestly.

In earlier times, the forum software sometimes ate posts if you took a time too long writing it (without either previewing it in-between every so often or submitting a first version right away and then editing it into a final version).

Possibly something similar to those time-outs happened here.

Mike wrote:

plbyrd wrote:My post got eaten again.

This time it wasn't me, honestly.

In earlier times, the forum software sometimes ate posts if you took a time too long writing it (without either previewing it in-between every so often or submitting a first version right away and then editing it into a final version).

EBKAC.

I previewed without saving.

Not sure the response was worth the effort of recreating it all. Short version: A cart based drive would be great, but it would need the banking features so that people wouldn't need to swap carts.

plbyrd wrote:Not sure the response was worth the effort of recreating it all. Short version: A cart based drive would be great, but it would need the banking features so that people wouldn't need to swap carts.

Agreed!

and: PM sent.

Now, I do really think that adapting the EasyFlash file format and EasyFS api would be a HUGE win for the Ultimem. There are many great tools available for EF that you could then leverage.