Ultimem or Final Expansion?

Discuss anything related to the VIC
brain
Vic 20 Nerd
Posts: 531
Joined: Sun Jul 04, 2004 10:12 pm

Re: Ultimem or Final Expansion?

Post by brain »

Mike, I apologize that Ultimem failed to impress you. I guess one can't be all things to all people.

I admit your idea of a mass storage solution with faster transfer speeds is enticing. I honestly did not think about it because I was afraid that folks would never buy a Ultimem+SD2IEC board that cost $100.00. Perhaps I was wrong.

I agree the lack of unified config app and framework is a miss. The main problem is that I am a HW person, and I thought that if I get the HW working, some enterprising folks would pop in and take care of the SW. I even sent some dev boards out to a handful of people to get things done. Sadly, little materialized.

As it stands, it has greatly tempered my desire to build more designs for the VIC-20. Without the unified SW, no one really wants the HW, and I can't justify producing the HW if no one will buy it. It's sad, really, because the VIC was my first machine, and I love the simplicity. I have 3-4 more projects on the bench for the VIC, but as I am not a SW dev, they will be at the mercy of someone who can write some code for them.

I thought I could address the issue by writing the menu/config stuff in C, but I tried and failed across 12 months to get cc65 to generate a ROM-ified app. RAM apps work fine, but ROM apps just lock up in init. My options exhausted, I await someone to rescue my feeble HW attempts.

Jim
User avatar
plbyrd
Vic 20 Hobbyist
Posts: 135
Joined: Tue Jun 01, 2010 9:32 pm
Website: http://thesharp.ninja
Location: Clarksville, TN
Occupation: Software Engineer

Re: Ultimem or Final Expansion?

Post by plbyrd »

Jim, i'll do it.
brain
Vic 20 Nerd
Posts: 531
Joined: Sun Jul 04, 2004 10:12 pm

Re: Ultimem or Final Expansion?

Post by brain »

plbyrd wrote:Jim, i'll do it.
I'd be most appreciative. I am happy to answer any HW questions, and I've got a few more pre-final boards here if you need one.

The EF3 menu is also C, and you can grab it from skoe's repo, if you can figure out how to get C to create a ROM-friendly app. That was my intention when I started the design.

A menu like EF3 would pop up, unless someone held a special key on boot. 3,8,6,2,5 would boot to 3K/8K/16K/32K/35K expansion, while a programmer would allow more files to be added, with a special place in the FLASH left for a directory of files, etc.

Marko's apps started to get there, but it is still lacking in some features, and the home page is pretty sparse.

Jim
User avatar
plbyrd
Vic 20 Hobbyist
Posts: 135
Joined: Tue Jun 01, 2010 9:32 pm
Website: http://thesharp.ninja
Location: Clarksville, TN
Occupation: Software Engineer

Re: Ultimem or Final Expansion?

Post by plbyrd »

I'm quite familiar with the process of making a rom image with cc65. I also already have an ultiram board to work with.
brain
Vic 20 Nerd
Posts: 531
Joined: Sun Jul 04, 2004 10:12 pm

Re: Ultimem or Final Expansion?

Post by brain »

plbyrd wrote:I'm quite familiar with the process of making a rom image with cc65. I also already have an ultiram board to work with.
I'd love to get a sample project. I worked with cc65 folks for so long, and none of the examples they helped with worked on the VIC-20

Jim
User avatar
plbyrd
Vic 20 Hobbyist
Posts: 135
Joined: Tue Jun 01, 2010 9:32 pm
Website: http://thesharp.ninja
Location: Clarksville, TN
Occupation: Software Engineer

Re: Ultimem or Final Expansion?

Post by plbyrd »

I will whip something up this week
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Ultimem or Final Expansion?

Post by Mike »

brain wrote:Mike, I apologize that Ultimem failed to impress you.
Taking this at face value: there is really no reason for you to apologize for anything. No harm was done. I merely expressed my disappointment over Ultimem after its design was finalised. And need I to admit it's too easy to criticise after the fact.

Given what you wrote in follow-up, the best outcome would be if there was a lesson we could learn from the mishap. What I think about your post, not strictly in order of how you wrote this:
Without the unified SW, no one really wants the HW, and I can't justify producing the HW if no one will buy it.
That's *really* bad news. :(

I can understand, that it is not in your interest to quote numbers when they're strictly below expectations. For the moment, I just hope you don't "sit" on a heap of unsold *assembled* cartridges ...
The main problem is that I am a HW person, and I thought that if I get the HW working, some enterprising folks would pop in and take care of the SW. I even sent some dev boards out to a handful of people to get things done. Sadly, little materialized.
That's at least one thing you should think over. On what basis did you give out the dev boards to the people? At least, there should exist a moral commitment to reciprocal service on their side, even if you both hadn't agreed upon a contract for specific work.

You really should call out to those people who received a dev board once again, with a friendly reminder. They owe something to you.
I admit your idea of a mass storage solution with faster transfer speeds is enticing. I honestly did not think about it because I was afraid that folks would never buy a Ultimem+SD2IEC board [...]
Just to remind you: I was not talking about an added-in SD2IEC. Rather, the cartridge would provide a much faster and more capable solution for well-behaving games and applications (i.e. those that use the standard KERNAL calls) than is possible with SD2IEC+JiffyDOS or SD2IEC+SJLOAD, because the transfers don't go anymore over the IEC Bus.

This is not something you get by 'bolting' a SD2IEC to Ultimem (like it's been done with FE3 - there the SD2IEC just gets the power supply from the cartridge infrastructure, but the connection still goes over extra cabling to the IEC port). It would require a completely new design, beyond a (even if very flexible) RAM/Flash-Expansion.

If anything, please reach out to Thomas Lövskog. He had those ideas laid out already in 2011 - sadly enough, his hardware designs went from creeping featurism to hibernation mode. If you two could come to an agreement to relaunch the project, please tell me.

...

I'd like to add the following thoughts, and it's clear to me they might come around somewhat harsh, but here we go:

People seem to accept, that hardware has its price. The hardware took some time to design and manufacture, that is its cost, and the seller has the troubles to test the hardware, package it, look over the financial transfers, etc. and charge whatever he finds appropriate to cover the costs. If it doesn't cover the cost, it's an hobbyist project.

For the most time, the programmers and coders here in Denial released their software without charging the people in any way. Over the years, that might have resulted in many people being cheap when it comes to compensate the programmers/coders for the time they spent programming.

The software does not come without cost! They all take their time to be designed, programmed and tested: like hardware is designed, built and tested! If in the past, most software was released here in Denial without asking anything in return, this was mostly because software - contrary to hardware - is easily copied once released. As programmer, you effectively have no control about this once the software is out in the wild. Why adding yourself the hassles obliging those few interested people to cover the software's cost, when most others think they can obtain it for 'free'?

I once gave the numbers for MINIPAINT, which I still consider one of the best pieces of software released for the VIC-20: during development, I spent roughly 100 hours on it. If I actually *needed* to compensate those costs, I'd have had to sell >300 copies at a reasonable price of $50/copy for $150 charged per working hour. Not that I ever had expected to sell that number of copies. The conclusion: I wrote it off as learning project, and otherwise, as spare time activity. Otherwise, if all active programmers here in Denial would take this into account, the software "output" only would have the choice to drop to zero. :(

For me, I'm nearly at that point. It's just some still inner source of motivation, that I still keep on writing software for the VIC-20. However, as I don't expect any (financial) compensation, I quite the same do not accept any 'orders'. From time to time, I'll release some works, whether or not other people might find use for them or enjoy them. Not more. Actually, there's another combined software/hardware project in my pipeline (tokra, pixel, eslapion, you know what I'm talking about!), and this time I am not going to release it as software-only, even though it was possible ... just because there wouldn't be any sense to do so! But at least that project will give me a lot new things to learn. :D

...

So, everything's just fine. Jim - once again - ask the people who got the dev boards, and please contact TLovskog about GCart 2011. If you two team up, I'll be the third to join in. :)

Greetings,

Michael
brain
Vic 20 Nerd
Posts: 531
Joined: Sun Jul 04, 2004 10:12 pm

Re: Ultimem or Final Expansion?

Post by brain »

Mike wrote:
Without the unified SW, no one really wants the HW, and I can't justify producing the HW if no one will buy it.
That's *really* bad news. :(

I can understand, that it is not in your interest to quote numbers when they're strictly below expectations. For the moment, I just hope you don't "sit" on a heap of unsold *assembled* cartridges ...
Given the design (and GCart 2011) being surface mount, unless someone is prepared to hand assembled with a stencil, oven, paste, and lots of time, one must have the unit professionally assembled. If that holds true, 100 units is the minimum to buy for economical reasons.
The main problem is that I am a HW person, and I thought that if I get the HW working, some enterprising folks would pop in and take care of the SW. I even sent some dev boards out to a handful of people to get things done. Sadly, little materialized.
That's at least one thing you should think over. On what basis did you give out the dev boards to the people? At least, there should exist a moral commitment to reciprocal service on their side, even if you both hadn't agreed upon a contract for specific work.
I gave out the boards with the expectation that they would deliver something. But, I also know Life(tm) happens.
I admit your idea of a mass storage solution with faster transfer speeds is enticing. I honestly did not think about it because I was afraid that folks would never buy a Ultimem+SD2IEC board [...]
Just to remind you: I was not talking about an added-in SD2IEC. Rather, the cartridge would provide a much faster and more capable solution for well-behaving games and applications (i.e. those that use the standard KERNAL calls) than is possible with SD2IEC+JiffyDOS or SD2IEC+SJLOAD, because the transfers don't go anymore over the IEC Bus.
I understood your initial request, but I modified it. You *cannot* bring a mass storage device into the CBM market that does not support the IEC protocol. The MMC64 proved that. The market will not accept it, and that ship sailed. However, it would be possible to attach the SD card on the sd2iec to the AVR through the CPLD, and then the VIC-20 can access the SD card directly. OR, one could leverage the FAT file system functionality in SD2iec and speed up the data transfer by putting a parallel port on the sd2iec (the space and pins are there already. I think ingo even wrote code for parallel transfers). But, you have to keep the IEC functionality. Sorry. And, while you may feel free to attempt to refute this, I can definitively tell you the market has made its wishes quite clear. Not saying I agree, just noting it.

For the most time, the programmers and coders here in Denial released their software without charging the people in any way. Over the years, that might have resulted in many people being cheap when it comes to compensate the programmers/coders for the time they spent programming.

The software does not come without cost! They all take their time to be designed, programmed and tested: like hardware is designed, built and tested! If in the past, most software was released here in Denial without asking anything in return, this was mostly because software - contrary to hardware - is easily copied once released. As programmer, you effectively have no control about this once the software is out in the wild. Why adding yourself the hassles obliging those few interested people to cover the software's cost, when most others think they can obtain it for 'free'?
While your statements may be true, I offered to pay some folks to write the SW for the unit.

As well, there's a fully functioning high speed UART on the VIC-MIDI cart, but no one has written a nice team for it as yet. Sigh...

Jim
alterus
Vic 20 Amateur
Posts: 68
Joined: Wed May 13, 2015 4:29 pm
Website: http://bbs.centronian.ca
Location: Victoria BC

Re: Ultimem or Final Expansion?

Post by alterus »

brain wrote: As well, there's a fully functioning high speed UART on the VIC-MIDI cart, but no one has written a nice team for it as yet. Sigh...
I would absolutely love to use the VIC MIDI to run a BBS, using the UART. I'm OK programming in C, and I've been doing a fair bit for the C64, running a BBS for a couple years now, but writing the code to handle the UART high speed transfer protocol is currently beyond me. If someone write a driver for the VIC MIDI, I will 100% use it to run a BBS.
alterus
Vic 20 Amateur
Posts: 68
Joined: Wed May 13, 2015 4:29 pm
Website: http://bbs.centronian.ca
Location: Victoria BC

Re: Ultimem or Final Expansion?

Post by alterus »

And yes, a quality term could also be written for the VIC MIDI. It would be nice to write the term and BBS software together, so they can take advantage of each other's features.
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Ultimem or Final Expansion?

Post by Mike »

brain wrote:I understood your initial request, but I modified it. You *cannot* bring a mass storage device into the CBM market that does not support the IEC protocol. The MMC64 proved that. The market will not accept it, and that ship sailed. [...] And, while you may feel free to attempt to refute this, [...]
Yes, I am going to refute this claim:

You are talking specifically about the C64 market. There, people until recently (with the advent of EF3) stuck onto 100% compatibility to a 1541. Everything else was not deemed acceptable. The SD2IEC likewise gets damned quite as well 'over there' because it is just 'too dumb' to let code executed on the drive. Etc.

The situation is quite different with the VIC-20. There, companies never got to write that specialist software that uses the 'finer' capabilities of the 1541 with its embedded CPU. I can count the software speeders with the fingers of one single hand. Other software that runs (partly) on the drive ...?

People are quite content with the SD2IECs on their VIC-20s. For 99%+ of the software, it works. With JiffyDOS and SJLOAD, it even runs at an acceptable speed. However, the sd2iec firmware got stuck in a rut: to 'please' the C64 people, Ingo bolted lots of extra code into the firmware, to detect common and less common software speeders, and then emulate their protocol. OTOH, the functionality on DOS level still isn't complete. With a SD2IEC, I'd gladly trade in full support of relative files in disk images and CBM partitions in 1581 disk images for the (for me) useless support of C64 fast loaders.

On the other hand, take the IEEE-488 cartridge. Given, that it was reproduced recently, it offers the same level of compatibiliy (from the OS view) as my proposed RAM-link-like SD-card access: Both solutions (need to) hook into the KERNAL vectors and supply their own transfer routines. From the software's point of view, it's even irrelevant that there is some device like the SFD-1001 attached behind the cartridge over the original IEC bus (I suppose there is exactly no single piece of software for the VIC-20 that runs code on the SFD-1001). It could quite as well be my proposed SD card solution, with optimized transfer routines. And then you have it: file I/O with >100 KB/s transfer rate. With just the standard KERNAL *calls* (which are wedged), instead of relying on non-standard memory banking mechanisms. A faster file I/O, which would benefit most of the existing games, tools and applications, not just those specifically written for the new cartridge.

So there...
brain
Vic 20 Nerd
Posts: 531
Joined: Sun Jul 04, 2004 10:12 pm

Re: Ultimem or Final Expansion?

Post by brain »

As I noted, you can refute the claim, but I stand by my original statement.

I agree with your technical rebuttal. I will concede that the technical concerns are C64/C128 based.

However, given the small size of the market, perception is stronger than technical merit. Since such compatibility can be achieved, any device that does not do so will be ridiculed, if not by VIC-20 users (because they know it does not matter), then the C64 users, which will cloud the acceptance of the product in the VIC-20 space. There is a significant overlap of VIC-20 and C64 users. Technical VIC-20 users will no doubt discard the useless opinions, but non technical users will be swayed. It happens today in the sd2iec space, when we both know that an sd2iec-based device will suffice for nearly all a non technical user would wish to do.

Also, consider your comment earlier in the thread. You spoke passionately about what you feel is a missed opportunity on the Ultimem, Can you not also see a similar comment from another user, essentially stating: "Jim *KNOWS* how to put IEC support into this device, and he squandered an opportunity to maintain compatibility on this device. I am disappointed". I'm not saying your perspective was unwarranted, but it can repeat.

Concerning your comment:
"OTOH, the functionality on DOS level still isn't complete. With a SD2IEC, I'd gladly trade in full support of relative files in disk images and CBM partitions in 1581 disk images for the (for me) useless support of C64 fast loaders."
I wrote the REL file support in sd2iec, and I understood it to be complete.. If there are bugs in the implementation, we should fix those.

As for 1581-style dirs, I can't argue with your desire, but the code to add that functionality (we started it), was horrendous and significantly error prone. There is plenty of room in the uC space to add it, but given the lack of usage and the complexity of supporting it, it was not continued. That does not change the end result, but I can assure you it was not for a lack of investigation.

Jim
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Ultimem or Final Expansion?

Post by Mike »

Jim,

for the moment I can't do much more than bring forward some arguments for the cause: if you're worried about the missing IEC support, it could of course be added as extra output in much the same way as Ultimate-II does. Mainly as fallback solution for mishaving applications. Of course that measure will incur extra cost.
brain wrote:[...] ridiculed [...]
People frown at or make fun of the strangest things. When I tell them I use RAM expansions with the VIC-20, they already accuse me of "cheating"! :lol:
brain wrote:I wrote the REL file support in sd2iec, and I understood it to be complete.. If there are bugs in the implementation, we should fix those.
The current READ ME on sd2iec.de tells something different:
unseen wrote:744 REL files:
745 ==========
746 Partial REL file support is implemented. It should work fine for existing
747 files, but creating new files and/or adding records to existing files
748 may fail. REL files in disk images are not supported yet, only as files
749 on a FAT medium. When x00 support is disabled the first byte of a REL
750 file is assumed to be the record length.
Regarding CBM partitions, I did not ask for them just because. There have been two releases for the VIC-20 by orion70 and me, where we found good use for CBM partitions to keep the main directory short and readable. Sadly enough, I never got to see those two releases on real hardware (unless I'd buy a 1581 again...). :(
brain
Vic 20 Nerd
Posts: 531
Joined: Sun Jul 04, 2004 10:12 pm

Re: Ultimem or Final Expansion?

Post by brain »

We're getting far afield, but I'll take a look at the REL file support as I get some time. I know I tested at least some of those things, as I remember the bugs and the need to start using the seek API in fatfs to make them work.

Jim
User avatar
plbyrd
Vic 20 Hobbyist
Posts: 135
Joined: Tue Jun 01, 2010 9:32 pm
Website: http://thesharp.ninja
Location: Clarksville, TN
Occupation: Software Engineer

Re: Ultimem or Final Expansion?

Post by plbyrd »

I have CBM-Command somewhat running from ROM images. I had to use some very specialized memory configurations to make it happen (CBM-Command is very large). I have ROM at banks 2, 3, 5 and RAM at bank 1. I have modified the crt0.s for the VIC-20 to start at $A000 with the cart header and the initialization code starting at $A009. From there it's pretty much all cc65 EXCEPT the CONDES region has to be copyied from ROM to RAM before initializing cc65's runtime. That took some time to figure out! Once you cross that hurdle the rest of the cc65 code is ROM-able. I had to define memory blocks and segments for the two continguous blocks of ROM. $A000-$BFFF gets written to a bin image and then $4000-$7FFF to another bin image. After the compile is complete I split the 16k file to two 8k bin images.

Are there any docs telling me how to construct an Ultimem compatible image with these files?
Post Reply